Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

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


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

...