Modifying Default User Permissions
Overview: By default, Vymo activates all user actions for every user, such as creating an account, viewing records, and editing profiles. However, granting everyone unrestricted access might not be optimal for every organization. You can fine-tune these permissions using the 'self-serve' feature.
Permission Categories: 1. User Permissions 2. Module Permissions 3. Record Permissions
Procedure:
Set Universal Restrictions: 1. Initiate by crafting a 'Default_All' category, turning off all user actions. This strategy creates a zero-permission baseline for every user.
Note on 'ALL' Role in Default Settings: - In the context of default roles, the 'ALL' role functions differently. It applies permissions across the board but allows for individual role customization. This is crucial for administrators to understand when setting up or modifying roles.
Define Permissions for Specific Roles: 1. For every user role, allocate their exclusive permissions.
Detailed Steps: a. Sign in to the Vymo web app. b. Follow this path: Self Serve > Global Settings > JSON Configurations. c. Within 'JSON Configurations', seek the settings object, expand its view, and identify the userRolePermission object. d. To grant permissions, add the roles to userRolePermission. To implement restrictions, initiate the 'Default_All' category, and turn all permissions to 'false'. Then, assign permissions to individual roles as necessary.
Considerations for New Role Creation and User Module Permissions: 1. When creating a new role without configuring user module permissions, and assigning this role to a user, the user may gain all permissions of the user module. To prevent this, ensure at least one permission is configured for new roles.
-
Be aware of the issue where an empty permissions object from the backend leads the frontend to default to granting all permissions. This requires attention in both the back-end and front-end logic systems.
-
Ensure that role configurations undergo rigorous validations to check for inconsistencies or errors.
Issue with Permissions in New Client Instances: 1. In cases where no permissions are given for the User Module in newly launched client instances, managers might still be able to add/edit user records. This issue can be fixed by configuring permissions for at least one client role and releasing the changes.
Problem with Module-Level Permissions: 1. When new roles are created in the system, ensure that they are accurately reflected in module-level permissions and implemented correctly for users with those roles.
Example Configuration: Below is a JSON blueprint illustrating the permissions associated with the 'zsm' and 'asm' user roles. Also highlighted is the 'DEFAULT_ALL' category, which is restrictive by design.
In this JSON structure, the keys like "zsm" represent the role codes, which are used in Self-Serve configurations. These role codes can sometimes be the same as the role name, especially for roles created manually through the global JSON UI. In most cases, however, they might be an alphanumeric key uniquely identifying each role.
```json { "userRolePermission": { "zsm": { "disableAdd": true, "disableVisibility": true, "disableLock": true, "disableEdit": false, "disableBulkUpload": true, "disableExport": true, "disablePasswordReset": true, "disableChangeManager": false, "disableBulkNotification": true, "disableNotification": true }, "asm": { "disableAdd": true, "disableVisibility": true, "disableLock": true, "disableEdit": false, "disableBulkUpload": true, "disableExport": true, "disablePasswordReset": true, "disableChangeManager": false, "disableBulkNotification": true, "disableNotification": true }, "DEFAULT_ALL": { "disableAdd": false, "disableVisibility": false, "disableLock": false, "disableEdit": false, "disableBulkUpload": false, "disableExport": false, "disablePasswordReset": false, "disableChangeManager": false, "disableBulkNotification": false, "disableNotification": false } } }
See also
- Roles Configuration