Overview

One outcome of a recent investigation into misleading permission set configuration (

Naming Conventions

1. Name the permission sets appropriately, e.g. avoid inclusion of POST/PUT/DELETE permissions in "*.view" permission sets.
   

   • Good: 

     Code Block
     language js
     { "permissionName": "ui-erm-usage.view-create-edit", "displayName": "eUsage: Can view, create and edit usage data providers and COUNTER reports", "id": "ade748af-66b5-4584-a319-3cac20899241", "description": "Can view, create and edit usage data providers and COUNTER reports", "tags": [], "subPermissions": [ "module.erm-usage.enabled", "usagedataproviders.collection.get", "usagedataproviders.item.get", "usagedataproviders.item.post", "usagedataproviders.item.put", "counterreports.collection.get", "counterreports.item.get", "counterreports.item.post", "counterreports.item.put", "aggregatorsettings.collection.get", "aggregatorsettings.item.get" ], "childOf": [], "grantedTo": [ "fba0106d-e2ad-494e-8958-ce5b447ab2aa" ], "mutable": false, "visible": true, "dummy": false }

     
     

   • Bad: 

     Code Block
     language js
     { "permissionName": "ui-receiving.basic.view", "displayName": "Receiving: Basic view", "id": "5542bb26-9eff-4699-a7c5-6e6a049979d7", "tags": [], "subPermissions": [ "module.receiving.enabled", "orders.item.get", "orders.pieces.item.post", "orders.pieces.item.put", "orders.po-lines.collection.get", "orders.titles.collection.get", "orders.titles.item.get", "ui-receiving.third-party-services" ], "childOf": [ "ui-receiving.view" ], "grantedTo": [], "mutable": false, "visible": false, "dummy": false }

     
     

2. Permission sets for modulePermissions should use the "modperms" prefix.  These also should not be visible as they aren't intended to be assigned to users.

   • Example: 

     Code Block

     "permissionName": "modperms.circulation.loans.anonymize", "permissionName": "modperms.circulation.override-renewal-by-barcode.post", "permissionName": "modperms.circulation.renew-by-barcode.post", "permissionName": "modperms.circulation.requests.item.move.post", "permissionName": "modperms.circulation.renew-by-id.post", "permissionName": "modperms.circulation.requests.item.post", "permissionName": "modperms.circulation.override-check-out-by-barcode.post", "permissionName": "modperms.circulation.requests.item.put", "permissionName": "modperms.circulation.requests.instances.item.post", "permissionName": "modperms.circulation.check-out-by-barcode.post", "permissionName": "modperms.orders.item.post", "permissionName": "modperms.orders.item.put",

     
     

3. TBD

Backend Modules

• 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 needs configuration.entries.collection.get, but "ui-users.view" probably doesn't.  If needed, additional permission sets should be created with appropriate names.

Other Considerations

• Sensitive information should NEVER be stored in mod-configuration. SMTP credentials, RMAPI credentials, etc. should be stored behind their own endpoints which are protected with distinct permissions.
• We might want to take a look at ways to make the permissions of this module more granular, perhaps something could be done using desiredPermissions / X-Okapi-Permissions? Though I'm not sure this is really doable or even worth it. I think I'm in favor of just moving away from mod-configuration all together (see below)
• We should consider moving away from using mod-configuration in general. The cross-app nature of this module makes it difficult to deal with other things like sample/reference data... what if you want some reference data loaded into mod-configuration, but not all of it?
• TBD