Skip to content

User permissions - #3908

Closed
ssddanbrown wants to merge 24 commits into
developmentfrom
user_permissions
Closed

ssddanbrown wants to merge 24 commits into
developmentfrom
user_permissions

Conversation

@ssddanbrown

@ssddanbrown ssddanbrown commented Dec 7, 2022

Copy link
Copy Markdown
Member

As start of user permissions work. Related to #1747.

Todo

  • Update entity permissions table
  • Update "Other users" permission handling to be denoted by entity permissions with user_id = null AND role_id = null instead of role_id = 0.
  • Update joint_permissions table to support user_id?
  • Update joint_permission handling.
    • Fix misalignment between joint and non-joint handling, Currently seen with 2-role user, granted view on parent book on Role A, prevented view on chapter on Role B.
      • Check scenario against release.
        • Release has this same scenario. Works if inherit permissions is inactive, otherwise chapter (and content) is visible but not accessible, even if both roles are set to not allow view while inherit is active.
    • Chapter permission fallback "Other users" option not taking account.
    • Check scenario of "Role A" granting permission via role permissions to sub-item that has blocked "Role B" permission at entity-level.
      • Check on release - Can view (query), can't access (userCan).
      • Check view via joint permission behaviour
      • Check edit via userCan behaviour.
  • Add user interface for user permissions.
  • Delete entity permissions and joint permissions on user delete.
  • Wrap gen/delete in transactions to avoid visibility change during generation.
  • Check for todos in changes.
  • Testing.
    • Create dev-doc for permission scenario testing, with test case IDs that link to PHPUnit test cases.
    • Test admin system role retains full item-level permission.
    • Manually & thoroughly scenario test permission application.
    • Ensure view (joint permission) logic aligns.
    • Check prevention (Lack of permission) aligns with last release, and pre-v22.10 release (Where applicable), in that role permissions will prevent access where defined (Unless another role for the user specifically allows).
    • Check copying of shelf permissions.
    • Check copying of items (If permissions come across.)
  • Extract text to language files.

Docs update

  • Update permissions user doc page.
    • Provide an "advanced" overview of deeper combination logic
  • Add upgrade notice, linking to above added section for more details.

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.
@ssddanbrown

Copy link
Copy Markdown
Member Author

Note of approach failure

Written 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.
This was a entity_permissions_collapsed that would store the collapsed/flattened/inherited role & user permission overrides only where item-level permission overrides were active. Permissions were then joined into queries so the fallback, role & user status would be worked out at query time.

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 (Totalling 7)
The performance/index usage was already questionable here.

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.
Think we should hold back on on changing the permission system in this way until we can zoom out and look at more fundamental potential changes to support (Aligning entities to single table).

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.
@ssddanbrown

Copy link
Copy Markdown
Member Author

Superseded by #3986, although in a different scope (No user permissions, mainly testing and alignment work)

@ssddanbrown ssddanbrown removed this from the v23.01 milestone Jan 29, 2023
@ssddanbrown
ssddanbrown deleted the user_permissions branch June 11, 2026 13:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

1 participant