Summary: | Sub-tools permission not applying on intranet-main.tt | ||
---|---|---|---|
Product: | Koha | Reporter: | Florian <florian.bontemps> |
Component: | Staff interface | Assignee: | Florian <florian.bontemps> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | minor | ||
Priority: | P5 - low | CC: | arthur.suzuki, gmcharlt, lucas, victor |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
22.11.00, 22.05.04, 21.11.11
|
|
Circulation function: | |||
Attachments: |
Bug 31067: Fixing missing permission check
Bug 31067: Fixing missing permission check Bug 31067: Fixing missing permission check |
Description
Florian
2022-06-29 15:15:23 UTC
Created attachment 136742 [details] [review] Bug 31067: Fixing missing permission check This patch just fixes a missing permission on the intranet main page. Currently, the Additional Content modules allows people to edit, modify or create new additional content just by checking if they have any tool permission at all, and not the right one. To test: 1 - From the staff client, create a news article for the intranet. 2 - Create (or use) an additional staff patron, giving them the necessary permissions to access the intranet, but no tool permission. 3 - Using another browser (or incognito mode), log on the intranet page with your new staff account, you should be able to see the news content, but not edit or delete it. That's the expected behavior. 4 - From your main admin account, give your test account the edit_additional_contents permission. 5 - Your test account should now be able to edit/delete the news content. This is also expected behavior. 6 - Using the main account again, remove this time the edit_additional_contents but add any other subtool permission (edit_calendar is a good one for instance) 7 - Repeat step 5 and confirm that your test account can still edit or delete the news content. This shouldn't happen. 8 - Apply patch 9 - Repeat steps 4-6, and confirm that your test account can now only edit or delete news content if they have the edit_additional_contents permission enabled. Created attachment 136745 [details] [review] Bug 31067: Fixing missing permission check This patch just fixes a missing permission on the intranet main page. Currently, the Additional Content modules allows people to edit, modify or create new additional content just by checking if they have any tool permission at all, and not the right one. To test: 1 - From the staff client, create a news article for the intranet. 2 - Create (or use) an additional staff patron, giving them the necessary permissions to access the intranet, but no tool permission. 3 - Using another browser (or incognito mode), log on the intranet page with your new staff account, you should be able to see the news content, but not edit or delete it. That's the expected behavior. 4 - From your main admin account, give your test account the edit_additional_contents permission. 5 - Your test account should now be able to edit/delete the news content. This is also expected behavior. 6 - Using the main account again, remove this time the edit_additional_contents but add any other subtool permission (edit_calendar is a good one for instance) 7 - Repeat step 5 and confirm that your test account can still edit or delete the news content. This shouldn't happen. 8 - Apply patch 9 - Repeat steps 4-6, and confirm that your test account can now only edit or delete news content if they have the edit_additional_contents permission enabled. Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Created attachment 137200 [details] [review] Bug 31067: Fixing missing permission check This patch just fixes a missing permission on the intranet main page. Currently, the Additional Content modules allows people to edit, modify or create new additional content just by checking if they have any tool permission at all, and not the right one. To test: 1 - From the staff client, create a news article for the intranet. 2 - Create (or use) an additional staff patron, giving them the necessary permissions to access the intranet, but no tool permission. 3 - Using another browser (or incognito mode), log on the intranet page with your new staff account, you should be able to see the news content, but not edit or delete it. That's the expected behavior. 4 - From your main admin account, give your test account the edit_additional_contents permission. 5 - Your test account should now be able to edit/delete the news content. This is also expected behavior. 6 - Using the main account again, remove this time the edit_additional_contents but add any other subtool permission (edit_calendar is a good one for instance) 7 - Repeat step 5 and confirm that your test account can still edit or delete the news content. This shouldn't happen. 8 - Apply patch 9 - Repeat steps 4-6, and confirm that your test account can now only edit or delete news content if they have the edit_additional_contents permission enabled. Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Pushed to master for 22.11. Nice work everyone, thanks! Backported to 22.05.x for 22.05.04 pushed to 21.11.x for 21.11.11. Good Game Florian and thank you everyone! Not backported to oldoldstable (21.05.x). Feel free to ask if it's needed. Nothing to document, marking resolved. |