Bug 31067 - Sub-tools permission not applying on intranet-main.tt
Summary: Sub-tools permission not applying on intranet-main.tt
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Florian
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-29 15:15 UTC by Florian
Modified: 2023-06-08 22:26 UTC (History)
4 users (show)

See Also:
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


Attachments
Bug 31067: Fixing missing permission check (2.97 KB, patch)
2022-06-29 15:34 UTC, Florian
Details | Diff | Splinter Review
Bug 31067: Fixing missing permission check (3.03 KB, patch)
2022-06-29 17:14 UTC, Lucas Gass
Details | Diff | Splinter Review
Bug 31067: Fixing missing permission check (3.10 KB, patch)
2022-07-06 09:02 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Florian 2022-06-29 15:15:23 UTC
News and content displayed on the main intranet homepage can be edited, deleted or created by anyone who has a tool sub-permission, even if it's not edit_additional_contents.
Comment 1 Florian 2022-06-29 15:34:43 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.
Comment 2 Lucas Gass 2022-06-29 17:14:42 UTC
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>
Comment 3 Jonathan Druart 2022-07-06 09:02:23 UTC
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>
Comment 4 Tomás Cohen Arazi 2022-07-06 21:37:35 UTC
Pushed to master for 22.11.

Nice work everyone, thanks!
Comment 5 Lucas Gass 2022-08-12 15:57:00 UTC
Backported to 22.05.x for 22.05.04
Comment 6 Arthur Suzuki 2022-08-16 10:06:59 UTC
pushed to 21.11.x for 21.11.11.
Good Game Florian and thank you everyone!
Comment 7 Victor Grousset/tuxayo 2022-08-19 20:44:49 UTC
Not backported to oldoldstable (21.05.x). Feel free to ask if it's needed.

Nothing to document, marking resolved.