User permissions - #3908
User permissions#3908ssddanbrown wants to merge 24 commits into
Conversation
As start of user permissions work
Now idenitifies fallback using role_id and user_id = null. Lays some foundations for handling user_id.
Also updated non-joint permission handling to support user permissions.
- Reset input after user selection. - Corrected permission row title text for user rows.
Some issues exist to resolve though, not in final state.
Following recent similar actions done for entities. Required at this stage to provider better & cleaner helpers for common user and permission actions to built out permission testing.
Also added definitions for general expected behaviour to readme doc, and added some entity role inherit scenarios to check they meet expectations. Currently failing role test but not an issue with test, needs fixing to app logic.
Also removed so no-longer-relevant todo/comments.
Also converted the existing "JointPermission" usage to the new collapsed permission system.
Got all current scenario tests passing. Also fixes own permission which was using the wrong field.
Also fixed search query issue with abiguous column
May be issues at points of use though, Added todo for this in code. Also added extra indexes to collapsed table for better query performance.
As part of the permission checking we need to check owner user status. Upon this, we'd also want to check page draft status (and its creator/owner). These, for cross-entity/relation queries would need up to another 4 joins. The performance/index usage is already questionable here.
Note of approach failureWritten at 55642a3 As part of this work I tried to bring the "cached" permissions, stored in the database, up a level so they're not per-role, per-item. As part of the permission checking we need to check owner user status. This approach now looks like the wrong path, since we're implementing large changes, adding significant risk, without proof of overall benefit. The improved cache-time performance and reduced joint permission table would be risking query-time performance, which may not work out long-term. For now, might need to look to tack-on user permissions to existing system, but we should be able to keep changes in non-query work. |
It has a large linear-entity-scaling performance impact though.
|
Superseded by #3986, although in a different scope (No user permissions, mainly testing and alignment work) |
As start of user permissions work. Related to #1747.
Todo
user_id = null AND role_id = nullinstead ofrole_id = 0.userCanbehaviour.Docs update