Rename settings-pages permissions *sigh*

Description

It's apparent that, in setting up permissions to guard the various settings pages provided by Stripes modules, I've somehow used two different naming conventions: some are named settings.PAGENAME.all and some are called ui-MODULENAME.settings.PAGENAME.

The latter is clearly better, so I will change all the permission names in the former mould to the latter.

Doing so naively would break the diku_admin permission assignments, so instead I plan to retain "skeleton permissions" with the legacy names, which have the new permissions as their only sub-permission – aliases, in effect. Later when Wayne has changed the diku_admin permission assignments to the new names, I can discard the aliases.

Environment

None

Potential Workaround

None

Checklist

hide

TestRail: Results

Activity

Show:

Mike Taylor September 1, 2017 at 7:09 PM

The new issue is . This one is done.

Mike Taylor September 1, 2017 at 7:06 PM

But things will work as they are set up now, so I will push the deprecation process into its own issue and close this one.

Mike Taylor September 1, 2017 at 7:04 PM

That means the new permission names are defined in all modules, and legacy permissions set up (invisible) that include them while we make the transition. Once we have new VMs that associate diku_admin with the new permissions, we can change their settings guards to the new permissions. once those modules are in wide use, we can remove diku_admin's association with the legacy permissions from the Ansible scripts; and finally, when that VM is in use, we can remove the old permissions from the modules' package files.

Sheesh.

Mike Taylor September 1, 2017 at 6:55 PM

Mike Taylor September 1, 2017 at 6:51 PM

Done

Details

Assignee

Reporter

Labels

Priority

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created September 1, 2017 at 6:10 PM
Updated September 2, 2017 at 1:23 AM
Resolved September 1, 2017 at 7:09 PM
TestRail: Cases
TestRail: Runs