-
-
Notifications
You must be signed in to change notification settings - Fork 529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Role Authority Editability #16568
Conversation
As mentioned out of context in #16469, I think we need to consider just letting authority be presented/editable directly as an integer authority value when editing ACLs. Or don't allow ACLs to be edited at all, only allowing them to be created (setting the authority from a role) and deleted. |
Actually, if we make modUserGroupRole.authority a unique index, we can rely on the link between a role and an authority. If no one has objections, I'll make this change, add the appropriate upgrade scripts, and add an upgrade test to ensure there are not multiple modUserGroupRole objects with the same authority before the upgrade to 3.1 can be executed. Then this PR can stand as is. |
Makes sense to me ;-) |
Ensure authority cannot be changed on assigned Roles
Formatting and code style fixes and optimizations
### What does it do? Adds a unique index to the modUserGroupRole.authority field. ### Why is it needed? modUserGroupRole records are linked to ACLs via the authority value, so those MUST be unique or referential integrity is lost. ### How to test Run the transport build, execute the setup, and verify that after adding a modUserGroupRole record with a non-unique authority value, the upgrade stops with a failure describing what you need to do in order to resolve the situation before re-running the setup. After removing the non-unique record, verify that setup then runs successfully and a unique index is added to the authority column. ### Related issue(s)/PR(s) This is related to and should be adopted along with #16568 — see discussion on that PR.
What does it do?
Add new listener routine to restrict editing based on whether a Role is assigned to an ACL entry. Also:
Why is it needed?
The ability to edit an assigned Role's authority leads to orphaned ACL rules that not longer show up in the manager, yet remain in the database. See the referenced issue below.
How to test
Note
The initial commit contains all substantive changes, while the follow up is just code-style/optimization oriented.
Related issue(s)/PR(s)
Resolves #16565