Project Permissions
Last updated
Last updated
The previous project permissions are now split further based on possible user activities possible within the system. This documentation provides an overview of the upcoming changes on project permissions.
The previous "Project Edit" permission is now split into five distinct permissions: "Project Management", "Dialog Management", "Release Management", "Release Debugging" and "Environment Management"
The previous "Edit Release Settings" is now associated with "Production Release Access"
The previous 'Debug (Phone 2) is now associated with "Production Release Access "
Training permission is now "Training Data Management". For accessing the Context in the training screen, ensure that the user has "Production Release Access"
The Export/Import Subdialog functionality, which was previously available to all roles, now requires the "Dialog Management" permission.
Note that the default roles in the system will function the same as before:
Admin role: Will still have access to all the new permissions.
Editor role: Will have access to all the new permissions except for user management.
Viewer role: Will not have access to any of the project permissions and user management permissions (they will be able to view projects by default).
For all custom roles, admin role must verify that their users have the required access.
Please note that all users invited to a project can view the project(s) and its elements such as graphs, releases, environments, and more. However, write operations on any of the project elements are only permitted with the appropriate permissions as outlined below.
Below are screenshots of the old and new permissions:
Project Management. Grants full control over project creation, modification, export, import, and deletion.
Dialog Management. Full control over dialog management, including manipulation of text snippets, intents, intent assignments, slots, dictionary entries, variables, services, graph editing, language addition, and version management.
Release Management. Permission to manage and configure non-production releases, including creation, updates, activation/deactivation, and NLU training.
Production Release Access. Permission to access, configure, and debug production releases. This should be used in conjunction with Release Management and Release Debugging permissions. Also includes the ability to view context in the training scene.
Environment Management. Permission to manage environments and their variables, including creation, editing, and deletion.
Training Data Management. Permission to add or ignore collected training data.
Release Debugging. Permission to debug any platform, excluding production releases
The permissions assigned to a role can now be restricted based on the specific activities the user performs within the system. For example,
Consider a custom role called 'project manager'. If you enable the 'Project Management' permission for this role, the user can add, edit, import, export, and delete projects, and nothing else. While this user can still view the projects they are invited to, they cannot perform any write operations on the project or its associated elements. Note that the importing subdialog into a project requires 'Dialog Management' permission
Similarly, for a custom role like 'debugger', providing 'Production Release Access' will allow these users to perform troubleshooting tasks on production releases without granting them permissions to edit dialogs, or any other project elements.
