Merge changes from next

README.md

@@ -37,6 +37,11 @@ You can then serve that production build using:
 npm run serve
 ```
 
+Note: If you are using a dev container within vscode, use this instead:
+```sh
+npm run serve -- --host 0.0.0.0
+```
+
 ## Contributing
 
 Take a look at the [contribution guidelines](https://github.com/galasa-dev/projectmanagement/blob/main/contributing.md).

src/data/nav.yaml

@@ -92,6 +92,8 @@
           items:
             - title: Ecosystem architecture
               path: /docs/ecosystem/architecture
+            - title: Role based access control
+              path: /docs/ecosystem/role-based-access
             - title: Installing an Ecosystem using Helm
               path: /docs/ecosystem/ecosystem-installing-k8s
             - title: Configuring authentication
@@ -128,6 +130,8 @@
           items:
             - title: CICS TS Managers
               path: /docs/manager-groups/cics-ts-manager-group
+            - title: IMS TM Managers
+              path: /docs/manager-groups/ims-tm-manager-group
             - title: Cloud Managers
               path: /docs/manager-groups/cloud-manager-group
             - title: Communications Managers

src/markdown-pages/docs/cli-command-reference/installing-cli-tool.md

@@ -32,8 +32,8 @@ On Mac:
 3. Then you have a choice. Either install the latest version fo the `galasactl` tool, or install a specific version.
     1. To install the latest version of `galasactl`: 
     `brew install --no-quarantine galasactl`
-    2. To install a specific version of `galasactl` (version 0.39.0 for example): 
-    `brew install --no-quarantine galasactl@0.39.0`
+    2. To install a specific version of `galasactl` (version 0.40.0 for example): 
+    `brew install --no-quarantine galasactl@0.40.0`
     Note: You can check to see what versions are available using this:
     `brew tap-info galasa-dev/tap --json` and look in the `"cask_tokens"` part of the json file.
 

src/markdown-pages/docs/ecosystem/ecosystem-architecture.md

@@ -67,3 +67,14 @@ The following diagram highlights some of the key components that make up the Gal
 | **Kabana**                       | A dashboard for visualizing Elasticsearch metrics. Data can be explored through queries and drilldown.       |
 
 </details>
+
+### Key concepts:
+
+These concepts are relevant when running tests locally, or when submitting tests to a remote Galasa service:
+- A **test case** - A piece of test logic which can be compiled or translated into something which is runnable by the Galasa framework. This may be a piece of Java code for example, or a Gherkin test feature.
+- A **test run** - Also known as a 'run' - An execution of the testcase which was started at a certain point in time, executed logic steps, and is still running, or has finished with a test status and result. For example: Passed or Failed.
+
+Some concepts are only relevant on a Galasa service:
+- A **user** - The authorised person manipulating the Galasa system in some way.
+- **Role based access control (RBAC)** - The mechanism where the Galasa service will allow some users to perform any available task, but limit what other users can do. This is to help isolate some system capabilities for safety or for security. Read more about the RBAC in the [role-based access](./ecosystem-role-based-access.md) section.
+

src/markdown-pages/docs/ecosystem/ecosystem-installing-k8s.md

@@ -23,7 +23,7 @@ _Note:_ The Galasa Ecosystem Helm chart currently supports only x86-64 systems.
 
 
 
-## Role-based access control
+## Kubernetes role-based access control
 
 If role-based access control (RBAC) is active on your Kubernetes cluster, a user with the `galasa-admin` role (or a role with equivalent permissions) is needed to run Helm commands on the cluster. The `galasa-admin` role allows assigned users to run the Helm install, upgrade, and delete commands to interact with the Helm chart. 
 
@@ -152,10 +152,33 @@ Complete the following steps to configure Dex to authenticate through GitHub:
               - my-team
     ```
 
-By default, the Galasa Ecosystem Helm chart creates a Kubernetes Secret containing configuration details for Dex. If you want to apply your own Dex configuration as a Secret, your Dex configuration must be provided in a `config.yaml` key within the Secret, and the value of the `config.yaml` key must be a valid Dex configuration.
+By default, the Galasa Ecosystem Helm chart creates a Kubernetes Secret containing configuration details for Dex. 
+If you want to apply your own Dex configuration as a Secret, your Dex configuration must be provided in a `config.yaml` key within the Secret, 
+and the value of the `config.yaml` key must be a valid Dex configuration.
 
 For more information on configuring Dex, see the  <a href=https://dexidp.io/docs target="_blank"> Dex documentation</a>.
 
+## Configure the default user role, and 'owner' of the Galasa service
+
+When the Galasa service is first installed, users logging in will be assigned a role as dictated by the `galasaDefaultUserRole` Helm chart property. For example 'tester'.
+This means nobody initially logging into the Galasa service will have administrator privileges.
+We would discourage ever setting this property to `admin` as doing so would provide a less secure Galasa service, with any action in the system available to anyone on the system.
+
+To obtain administration rights to the Galasa service, the kubernetes install must nominate one or more users as 'owners' of the service.
+When a service owner next logs into the Galasa service, they will be granted a role of `owner`.
+From this point on, that user can assign the 'admin' role to anyone else who needs it using the `galasactl` command line or by using the web user interface via a browser.
+
+Once the Galasa service has one or more users with the 'admin' role, kubernetes can be updated so that the system doesn't have any "owner" if desired. 
+The `owner` role exists solely to fix situations where there are no administrators on the Galasa service, such as when the Galasa service is initially installed, or when none of the
+members in the organisation have the `admin` role.
+If a user was a nominated "owner", performs some administration tasks, and is then removed from the list of "owners", their role on the Galasa service will revert to what it was initially.
+
+To configure a list of owners, use the `galasaOwnersLoginIds` property of the `values.yaml` file and use Helm to deploy it.
+You can set multiple owners by adding a comma-separated list of login-ids.
+
+Each login-id must match the login-id allocated to the user by the authentication service to which Galasa connects.
+If you are unsure what login-id to use, try setting up your system without an owner and logging into the Galasa service using a browser, then viewing the user profile page before returning to update the owner login-id in your `values.yaml` and deploying it to kubernetes using `helm upgrade`.
+
 ## Installing the chart
 
 After configuring your `values.yaml` file, complete the following steps to install the Galasa Ecosystem Helm chart:
@@ -214,22 +237,22 @@ Once you have successfully installed the Ecosystem, you can then deploy your Gal
 ## Upgrading the Galasa Ecosystem
 
 
-Get the latest version of the Ecosystem chart and upgrade the Galasa Ecosystem to use the newer version of Galasa - for example version 0.39.0 - by running the following command:
+Get the latest version of the Ecosystem chart and upgrade the Galasa Ecosystem to use the newer version of Galasa - for example version 0.40.0 - by running the following command:
 
 On Mac or Unix:
 
 ```console
 helm repo update \
 helm upgrade <release-name> galasa/ecosystem --reuse-values \
---set galasaVersion=0.39.0 --wait
+--set galasaVersion=0.40.0 --wait
 ```
 
 On Windows (Powershell):
 
 ```console
 helm repo update `
 helm upgrade <release-name> galasa/ecosystem --reuse-values `
---set galasaVersion=0.39.0 --wait
+--set galasaVersion=0.40.0 --wait
 ```
 
 where:<br>