...

• 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.

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 }

    
    

...

• 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 altogether (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?
  • See 

    Jira Legacy
    server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key FOLIO-2583

  • One use case where it probably makes sense to continue to have centralized configuration is for things that are truly shared across multiple apps, e.g. the tenant settings
• How do we handle "migration" of permission sets as teams clean things up?
  • One idea is to do something like add a field to the module descriptor that allows you to specify that this permission set "replaces" one named XYZ.  This would result the swapping and cleanup of permissions.
  • A spike is likely forthcoming for this.

...