Table of Contents |
---|
...
title | WIP |
---|
...
Overview
One outcome of a recent investigation into misleading permission set configuration (
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
...
- Avoid inclusion of other modules permissions in your permission sets. For example, mod-foo's permission set foo.all shouldn't include mod-bar's bar.item.get permission. Here it's the module that needs the permission, not the user.
- Do: include the other module's permission(s) in your modulePermissions (or non-visible modulePermission sets - see above)
- Don't: include other modules permissions in your visible permission sets that will be assigned to users.
UI Modules
- Define separate permission sets for settings if other other module permissions are needed (e.g.
configuration.entries.collection.get
).- Example: "
ui-users.settings.customfields.edit
" probably needsconfiguration.entries.collection.get
, but "ui-users.view
" probably doesn't. If needed, additional permission sets should be created with appropriate names.
- Example: "
Using *.all Permissions
- Only include *.all permissions when absolutely sure it's necessary/appropriate. Instead use just the permissions actually needed.
Example of a permission set that probably abuses *.all permissions
Code Block { "permissionName": "ui-checkin.all", "displayName": "Check in: All permissions", "id": "094310c8-cd71-4b76-a10d-2921ccd10654", "description": "Entire set of permissions needed to use Checkin", "tags": [], "subPermissions": [ "circulation.all", "circulation-storage.all", "configuration.all", "users.collection.get", "usergroups.collection.get", "module.checkin.enabled", "inventory.items.collection.get", "inventory-storage.service-points.collection.get" ], "childOf": [], "grantedTo": [ "fba0106d-e2ad-494e-8958-ce5b447ab2aa" ], "mutable": false, "visible": true, "dummy": false }
...