Hide image upload options in Image Manager when user lacks permission #6213
No reviewers
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 assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
bookstack/bookstack!6213
Loading…
Reference in a new issue
No description provided.
Delete branch "ps816/bookstack:fix-image-upload-permissions"
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?
Fixes #6148
Details
Hi Dan, this reported permission issue page has been fixed by removing upload button for not-authorized users and keeping a text "You do not have permission to upload new images.".
Changes:
resources/views/pages/parts/image-manager.blade.php - checks upload permission, passes it to the JS component
resources/js/components/image-manager.js - hides the upload button/hint and disables drag-and-drop when permission is missing
lang/en/components.php - added the "no permission" message text
tests/Uploads/ImageTest.php - test covering both permission states
Everything stays the same for users who do have permission.
I have tested before and after the changes using my local instance and shared screenshots for your reference. Please let me know if any corrections required.
Thanks
Regards
Samy
PS816.
Checklist
Thanks for offering this @ps816, is looking good from a quick look over.
If the text/button control does not need to be dynamic (does not change via JavaScript at any point) I'd probably prefer them to simply be controlled on the PHP/blade side, which would mean there's less options/references to pass through and handle/control on the JavaScript side, and therefore have a simpler result.
Thanks Dan,
Makes sense. Controlling the show/hide behaviour purely on the Blade side keeps things in one place rather than split between PHP and JS.
I will move that logic to Blade and update the PR.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.