Skip to end of banner
Go to start of banner

DR-000014 - Migration of Static Permissions Upon Upgrade

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 13 Next »

Submitted Date

 

Approved Dateyyyy-mm-dd
StatusACCEPTED
ImpactMEDIUM

 

Overrides/Supersedes 

This decision was migrated from the Tech Leads Decision Log as part of a consolidation process.  The original decision record can be found here.

RFC 

N/A

Stakeholders

Jakub Skoczen  Julian Ladisch Adam Dickmeiss Hongwei Ji

Contributors

Craig McNally 

Approvers

This decision was made by the Tech Leads group prior to the adoption of current decision making processes within the FOLIO project.

Background/Context

The purpose of this spike is to investigate how to implement static permission migration.  That is, how to handle when permissions & permission sets defined in module descriptors are renamed, removed, or updated (e.g. to include new permissions) during a module upgrade.  This does not cover the case of user-defined module permission sets.

Assumptions

N/A

Constraints

N/A

Rationale

The following statements apply to permissions defined in module descriptors.  NOT user-defined permissions.

  • Permissions can now be renamed via a new "replaces" property.  Perm-users (Assignments) will be updated automatically.
  • When permissions that once appeared in a module descriptor are removed in a newer version of the module descriptor, they will be marked deprecated. 
    • Initially the displayName of these permissions will be prefixed with "(deprecated)", but the permissions will not be filtered out of any API calls.
    • Eventually these permissions remain assigned to users, but will be filtered out of perms API results unless a new query argument (includeDeprecated=true is specified).  This will be handled in a separate story which may not make it into R1 2021.
  • A new API will be introduced to allow an operator to purge deprecated permissions.  Once this is done a module downgrade will not result in those permissions being re-assigned.
  • If a permission name collides with an user-defined permission with the same name,
    • Initially the call to enable the module will fail with an appropriate error message.  
    • Eventually we may do something like rename the user-defined permissions and adjust assignments as needed.
  • Going forward, all system-defined permissions will include context about the module that defined them (new permission fields moduleName/moduleVersion).
  • When upgrading mod-permissions, OKAPI will "refresh" all the existing permissions, this is already done when first enabling mod-permissions, but now will be done on upgrades as well.  
    • In most cases this will be a no-op, but this allows us to update permissions w/ the module context.

Decision

Static permission removal will use a soft delete to accommodate module downgrades

Implications

  • Pros
    • N/A
  • Cons
    • N/A

Other Related Resources

  • No labels