Cht-core: Can remove permissions from "Full Access" user

[alxndrsn]

It's possible to deny permission to some features for the so-called "Full Access" user:

Either this user should not be described as "full access", or it should not be possible to restrict permissions from this user.

[nice-snek]

hi frand @estellecomment, U is coot

Please close or schedule before the end of this sprint. See triaging old issues.

Nice Snek

[estellecomment]

Makes sense to me, setting Scheduled.
(I'd go for keeping the Full Access user, leaving it displayed, but blocking all the checkboxes to checked)

[nice-snek]

hi frand @abbyad, please triage before the end of this sprint.

[alxndrsn]

This has already been triaged.

[cbrwizard]

Hey, looks like by default 'Full access' users have some permissions unchecked on an almost clean system on master.

Looks quite confusing. Is it intended? If so, should it be possible to check/uncheck them but not uncheck other permissions?

Update: on the other hand, I was able to create/update persons while logged in as a Full access (not admin) user, even though my permissions for updating/creating users were visually unchecked. Looks like that the code doesn't actually check for these permissions, but checks if a user has full access (haven't found yet how it does that so I can't be sure atm).

I conclude that all permission checkboxes should be visually checked for a Full access user and disabled. Or did I miss something?

[alxndrsn]

Hi @cbrwizard! As per your findings and the discussion above, these permissions boxes don't actually do anything for full_access users. Fix is either to get rid of them, or set them all to be both checked and disabled.

[garethbowen]

The user role formerly known as "full access" is for people who can access all docs, but not necessarily have all permissions so being able to remove permissions is actually correct in this case. I completely agree the name is misleading so I've updated it to "National manager - access to all docs". It's not a role we use much any more and the design team are currently going through a role and permission redesign so I expect it'll change a lot then, perhaps to have a configurable set of roles rather than these hardcoded ones.

@cbrwizard You actually found another bug where the can_create_people and can_create_places were not being used in the UI, only in the API we use for scripting.

@alxndrsn Please code review both of these fixes in the attached PR.

[cbrwizard]

@garethbowen gotcha. I guess this issue can be renamed then.

[garethbowen]

Merged.