Skip to end of banner
Go to start of banner

Permission Set Guidelines

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Overview

One outcome of a recent investigation into misleading permission set configuration ( FOLIO-2565 - Getting issue details... STATUS ) is the proposal of new guidelines for permission sets.  This document serves as a place to capture that proposal and elicit feedback from others and facilitate discussion. 

Naming Conventions

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

    • Good: 

      {
  "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: 

      {
  "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: 

        "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



  • No labels