ACM : Access control managament
A list of known bugs that will soon be fixed is available at the end of this article.
What happens with the old workspace types (Private, Open, Limited)?
With the new ACM system, these workspace types (Private, Open, Limited) will be removed and will no longer be available when creating a new workspace.
All newly created workspaces will be closed by default, meaning only workspace admins will have access until they grant access to other users.
When creating a new workspace, is it closed or open by default?
With the new ACM system, all workspaces will be closed by default. This means that when a user creates a new workspace :
Regular users (readers and stewards) will not have access to the workspace modules and sources.
Only the workspace admins will be able to view, edit, and manage all workspace modules and sources.
Who is the admin of a newly created workspace?
The user who creates the workspace automatically becomes its first WS admin. Initially, they are the only one with access. They can then:
Define other workspace admins.
Define rules to grant access to users.
How can we add other admins to a workspace?
The first admin (workspace creator) can add additional admins by following these steps:
Go to the Access screen.
Navigate to the Features tab.
Click on the pencil (✏️) icon to open the rule preview.
Select additional users from the user list. Only users with steward licence are listed and can be selected.
How can we open the workspace to all users?
By default, new workspaces are closed. However, the admin can quickly open access so that all users in the client space can view all modules of the new workspace.
To do this, the admin should:
Click on the "Create Open Rule" button.
Review the pre-filled fields which include:
Selector: "All Users"
Selector: "All Modules & Sources"
Permission: "Can View"
Click on the "Create" button.
If the admin keeps the pre-filled fields as they are and clicks "Create", the Open Rule will grant view-only access to all users in the client space, across all modules and sources within the workspace. This is a dynamic rule, meaning it automatically includes both current and future users.
How can we grant access to a module or source to users?
Access is granted by creating a rule.
How do we create a rule?
Click on the "+" button to create a new rule.
What are the components of a rule?
A rule consists of the following components :
Rule Name
Description (displayed only in the rule preview after its creation)
Users and/or Teams the rule applies to
Permission Level (e.g., view, edit)
Modules and/or Sources the rule applies to
What are the new permission levels?
The new system includes only two permission levels:
View
Edit
What happens to the "Admin" permission level on a module or source?
The Admin source/module permission level has been removed and is now merged into the Edit permission level.
Here’s what changes:
Admin permission is no longer available for modules/sources.
Users previously having an Admin permission on modules/sources have now an Edit permission.
Edit permission now includes import and export permissions
For status / life cycle management, the Admin role is decommissioned (see the status lifecycle matrix).
Edit permission (with Steward licence) is now managing all the life cycle status, including "Validated" and "Obsolete" statuses. (Admin permission is not required anymore).
What type of access does a user need to import and/or export a module/source?
With the new Access Control System, the Admin source/module permission level has been removed and merged into the Edit permission level.
To import and/or export a module or source, the user must have a Steward license, and the Workspace Admin must grant them Edit permission for the module/source.
PS: For the dictionary, the full export is restricted to workspace administrators only.
How does the new access control system affect status / life cycle permissions?
The Admin role has been removed for status / life cycle management (see the status lifecycle matrix).
Edit permission (with Steward licence) is now managing all the life cycle statuses, including "Validated" and "Obsolete" statuses. (Admin permission is not required anymore).
Can we create a rule for a Team?
Yes, it's possible to apply a rule to different groups. You can select:
A single user
Multiple users
A team
Multiple teams
Users and teams
The rule will apply to all members of the selected teams and/or users.
What happens if the same user is included in both a View rule and an Edit rule for the same module/source?
The user will receive the higher permission level, meaning they will have Edit rights on the module/source.
What happens if a team member has a Reader license, but their team is included in a rule with Edit permission?
Since Reader licenses do not allow Edit permission, these users will not be included when the rule is applied.
What happens if we disable a rule?
When a rule is disabled, the access permissions granted by that rule are temporarily removed for all users included in it.
However, you can reactivate the rule at any time to restore the access rights.
After the migration to the new Access Control system, will users lose all their access rights? Will the admin need to recreate rules to grant access to users?
No, users will not lose their access rights.
We will ensure a smooth migration to the new Access control system by automatically generating rules that replicate the existing access rights. Admins will not need to manually recreate rules.
Can I apply a rule to all users?
Yes. To apply a rule to all users, enable the "Applies to all users" toggle when creating the rule.
This will include all current users in the client space, as well as any users added in the future.
However, keep in mind that the rule will only be applied according to each user's license. For example, if a user has a Reader license and the rule grants Edit permissions, the rule will not apply to that user.
What does "All users" include?
The "All Users" group is a system team that includes all existing users in the client space, as well as any future users added. This means that if you create a rule for all users, any new users added to your space will automatically be included—no manual updates required.
How can all users view the glossary while only a specific team can edit other modules?
You can achieve this by creating two rules:
First rule: Enable the "Applies to all users" toggle, set the permission level to "View", and apply it to the Glossary module.
Second rule: Select a specific team, set the permission level to "Edit", and apply it to the other modules.
Known Bugs (to be fixed in the coming weeks)
- When creating a new space, its name does not automatically appear in the breadcrumb. → Temporary workaround: refresh the page.
- The name of the new space also does not automatically appear in the workspace list. → Temporary workaround: refresh the page.
- When opening the preview of a rule and then refreshing the page, the user list becomes empty. → Temporary workaround: refresh again.
- Access types of spaces are always displayed in the workspace table. → To be ignored for now.
- When an admin updates the user list of a rule, a toaster message incorrectly states: "Your rights have been updated." → To be ignored.
- A toaster message appears when trying to activate or deactivate a rule linked to a deleted team.
- Issues related to the last modification date of rules. → To be ignored.
- A rule mentioning a deleted user or team remains visible, although it is no longer applied. → To be ignored.
- When a user loses access rights to a space, they are not automatically redirected to the workspace list. They still see the modules but cannot make any changes. → Temporary workaround: refresh the page.
- The 'Created by' field (in a rule preview) for rules created after the migration is empty. → To be ignored.
- For versioned spaces, each source access is managed within its corresponding workspace version. Soon, it will be possible to manage all available sources across all versions.