Content created as Admin becomes invisible after role demotion to "own"-scoped role, joint_permissions.owner_id set to NULL after regenerate-permissions #6097
Labels
No labels
Focus: A11y
Focus: Admin/Meta
Focus: Authentication
Focus: Back-End
Focus: Database
Focus: Design & UX
Focus: Editor - Markdown
Focus: Editor - WYSIWYG
Focus: Export System
Focus: Front-End
Focus: Translations
Focus: View Customization
Is: Docs Update
Is: Enhancement
Is: Priority
Is: Security
Is: Upstream
Status
Blocked
Status
Open to discussion
Status
Out of scope
Status
Pending Validation
Type
API Request
Type
Bug Report
Type
Feature Request
Type
Happy feedback
Type
Maintenance
Type
Question
Type
Support
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
bookstack/bookstack#6097
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the Bug
When a user who was previously an Admin gets demoted to a non-admin role with "own"-scoped asset permissions (e.g. "View own books"), the content they created as Admin becomes invisible to them. Running php artisan bookstack:regenerate-permissions does not fix the issue.
Root cause: After regenerate-permissions, the joint_permissions table has owner_id = NULL for non-admin roles, even though entities.owned_by and entities.created_by are correctly set to the user's ID. BookStack's permission query grants access via owner_id = <user_id> — with NULL, access is denied despite the user being the owner.
Steps to Reproduce
Expected Behaviour
regenerate-permissions should populate joint_permissions.owner_id from entities.owned_by for all roles, including non-admin roles with "own"-scoped permissions.
Screenshots or Additional Context
Workaround
Creating a dedicated role with "View all" scope for the affected user restores visibility, but is not a clean solution for multi-user setups with strict "own"-scoped isolation.
Browser Details
No response
Exact BookStack Version
v26.03.3
Hi @bedeberger,
Could I just check, for the scenario in question, have any permission changes be made to the book itself?