In ALM Octane, there are different spaces, or contexts, within which you can work, depending on your permissions. This topic discusses how to manage spaces.
Spaces are the contexts in which an ALM Octane user can work, depending on permissions.
Spaces are containers for workspaces. For details on workspaces, see Manage workspaces.
Space admins manage spaces. The space admin can associate workspaces to a space, define users, and set API access. For details on the space admin's capabilities, see Space admin.
Some entities are defined on the space level. These include users, API keys, and so on.
The space admin can create the following types of spaces: Isolated and shared.
The space admin can define users and API access.
Each workspace associated with an isolated space has its own set of data, which only admins for the workspace can customize.
The icon indicates the space is isolated, and when displayed next to an entity, indicates that the entity is not shared across workspaces.
The space admin can define users and API access.
Additionally, the space admin can customize data to be shared across workspaces (Enterprise Edition).
Shared entities includes releases, user-defined fields, forms, and so on.
The icon indicates the space is shared, and when displayed next to an entity, indicates that the entity is shared across workspaces.
Some entities can be customized both for shared spaces (affecting all associated workspaces) and also for individual workspaces. Only the admin for workspaces can customize entities for their individual workspaces.
|Customizable for shared spaces only, affecting all associated workspaces||Customizable for
all workspaces associated with a shared space, and also for individual workspaces
|Customizable for individual workspaces only|
There are three development divisions in your company: Hardware, Software, and Internal.
The hardware, and its accompanying software, must be released on the same release schedule and are made publicly available. Even though processes for these two divisions' deliverables might be different, the release schedule is the same. Also, a subset of testers test both hardware and software.
Internal development activities are on a different schedule and have nothing in common with the other two divisions' activities.
Enterprise Edition:Create a shared space called External_Deliverables.
Enterprise Edition:In the shared space External_Deliverables, create a workspace called Hardware and a workspace called Software. These workspaces will share releases and users.
Create an isolated space called Internal_Deliverables. Create an Internal workspace in this space. The workspaces in this space do not share information with any other workspaces.
Enterprise Edition: Create programs for the Internal, Hardware, and Software workspaces. Examples of programs you might create for the Software workspace could be MyAppWeb and MyAppMobile.
Tip: For strategies for setting up your spaces and workspaces, see the space definition strategy white paper.
Tip: For strategies for setting up your spaces and workspaces, see Best practices for setting up spaces and workspaces.
The site admin can view all the spaces for the site. For details, see View spaces for a site.
The site admin can create and rename spaces for the site. For details, see Manage spaces at the site level.
Modify and customize settings for a space.
In Settings > Spaces, and then select the space.
Edit the space by adding users, and setting up API access.
If the space is shared , you can also add releases, teams, UDFs, forms, workflow, rules, and so on.
Space admins create workspaces. Admins for workspaces then manage the workspaces.
In Settings > Spaces, navigate to the relevant space.
Click Add Workspace in the left pane. Name the workspace, add a description, and assign an admin for the workspace.
Workspace names are unique within a space.
Assign an admin for the workspace, and workspace members. Assign other roles to users as necessary in the workspace. For details, see Assign or remove roles.
Tip: If you need to edit the workspace settings, for example, to create releases, rules, and so on, assign these admin permissions to yourself.
Space admins can disable and enable workspaces.
Disabling a workspace makes its data temporarily inaccessible. This operation can be undone by enabling the workspace.
When a workspace is disabled, the data is retained and can be made accessible again after the workspace is enabled.
Reasons for disabling workspaces
Here are some use cases for why you might want to disable a workspace:
Put a project "on hold" temporarily, for example if no work is being done on this project. Deactivating the workspace retains the data and you can enable the workspace if the project is prioritized again. Then you can continue working on it.
Access data for a project for auditing purposes only, before archiving it.
You are about to make a major project customization or maintenance change, and you do not want users to work on the project until the changes are completed.
Effects of disabling a workspace
If the workspace a user last accessed is disabled, they are redirected to another one. If there is no enabled workspace available, the user is prompted to contact the admin.
Users cannot access a disabled workspace. It does not appear in the drop-down list in the top banner. Similarly, REST API requests cannot access a disabled workspace.
In Settings, disabled workspaces are displayed in gray.
Admins with workspace permissions can still add users to disabled spaces.
Data from a disabled workspace still appears in cross-workspace graphs, as data from any workspace would. There is no indication that the graph contains data from a disabled workspace.
Disable a workspace
In Settings > -> Spaces, select the workspace and click .
If prompted, give yourself administrative permissions for the workspace.
If prompted, confirm that you do want to temporary disable, or enable, the workspace.
Deleting a workspace makes its data inaccessible. For example, any data from the workspace that appeared in a cross-workspace graph is no longer displayed. This operation cannot be undone.
Space admins can delete workspaces.
Every space has at least one active workspace. the default workspace. The original name of this workspace is default_workspace. It can be renamed but it cannot be deleted.
If the workspace you last accessed is deleted, you are redirected to the another one.
In Settings -> Spaces, select the workspace and click .
When prompted, give yourself administrative permissions for the workspace.
When prompted, confirm that you do want to delete the workspace.
User management includes adding users, including existing users to workspaces, adding roles to users, and so on.
In Settings , depending on your permissions, click Site or Spaces.
Select the Users tab.
- In the Users tab, click Add Filter, select Roles and Workspaces > Role, and select the roles by which you want to filter.
- To further narrow down your results by workspaces, click Add Filter again, select Roles and Workspaces > Workspace, and select the workspaces by which you want to filter.
Add or edit users, depending on your role.
Note: Roles can be customized. Roles and their permissions might be different for your organization.
User management capability Site admin (on-premises) Shared space admin Admins for workspaces Add users to the current context (site, space, or workspace). For details, see Assign roles and permissions. Add users to the current context (site, space, or workspace) using the REST API. For details, see POST: Create a user. Import LDAP users to a space. For details, see Include LDAP users in ALM Octane (on-premises). On-premises: On-premises: Import IdP users for SSO authentication. For details, see Import IdP users for SSO authentication into a workspace (on-premises). On-premises: Add existing users from the space into the workspace. For details, see Include existing users into a workspace. Remove roles from a workspace user. For details, see Assign or remove roles.
Choose the fields to display in the user list, sort the list, and export the list to Microsoft Excel.
On-premises: Set user passwords.
Assign additional roles to users. For details, see Assign to, or unassign roles from, existing users.
Site admin can only assign the space admin role.
Assign the site admin role to other users. For details, see Assign the site admin role to existing users (on-premises). Activate and deactivate users. For details, see Assign roles and permissions. On-premises: SaaS: SaaS: Delete a user. For details, see Delete a user.
Available workspace storage is set on the space level, and not per workspace. This means the amount of total available workspace storage is shared between the workspaces in the space.
On-premises: Site admins can set the maximum size for storage per space with the STORAGE_MAX_SIZE configuration parameter. For details, see the information about setting the maximum size for storage (STORAGE_MAX_SIZE) in the ALM Octane Installation Guide.
The site admin can upgrade spaces for the site. For details, see Upgrade spaces.
Background jobs include processes that run after upgrading a space, among other activities. A space is only fully upgraded after all background jobs have completed successfully. The site admin can check periodically to see when an upgraded space is ready.
For details, see See a space's background jobs.