Bug 37849 - Permissions for additional content - HTML Customizations, Pages, News, OPAC, etc
Summary: Permissions for additional content - HTML Customizations, Pages, News, OPAC, etc
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-05 17:08 UTC by Sally Lodico
Modified: 2025-03-31 13:53 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sally Lodico 2024-09-05 17:08:27 UTC
We need more granular permissions to control who is allowed to create and edit additional content now that so many options to edit both the staff interface and the OPAC continue to be moved out of systems preferences. The only permission is edit_additional_content and it's all or nothing. It's one thing to allow a branch manager to add some news to the staff interface for their branch. It's another thing entirely to allow them to create and edit information that will display everywhere, or damage (intentionally or not) pages and content created by others. 

I suggest there be 2 new permissions that allow editing News items in the staff interface. One permission would be to edit their own library's News e.g. edit_own_news and the other to edit all News items e.g. edit_any_news.

Creating or editing any other type of additional content would be reserved for those with the edit_additional_content permission.

Bug 35693 Granular Permissions to Everything also mentions this issue, but appears to be intended to encourage developers to remember to address permissions issues when rolling out enhancements and new features.
Comment 1 David Cook 2025-03-03 03:35:02 UTC
(In reply to Sally Lodico from comment #0)
> I suggest there be 2 new permissions that allow editing News items in the
> staff interface. One permission would be to edit their own library's News
> e.g. edit_own_news and the other to edit all News items e.g. edit_any_news.

Historically, these types of permissions wouldn't really fit with how we do permissions/authorizations, but "view_borrower_infos_from_any_libraries" has set a precedent for these more complicated permissions.

I suppose "edit_own_news" and "edit_any_news" would essentially be the same as "list_borrowers" and "view_borrower_infos_from_any_libraries", but with a better naming convention.

Personally, I would think "edit_any_news" should be mutually exclusive with "edit_own_news" but we probably don't need to worry about that at this point.

I look forward to seeing other comments, but I think this probably sounds all right. I think it implies a future direction that the permission model needs to go and that's taking into consideration more the "subject" and "object" of the action (ie verb).
Comment 2 Juanita Jayne 2025-03-31 13:53:10 UTC
I'd like to see more granular permissions also. We would like to restrict some of those who can create News items to only be able to create their own and not be able to rearrange or edit the existing (shared) News items. Additionally, I think we should be able to restrict who has the ability to make HTML customizations. Right now, if we turn on the ability to edit & create News items, HTML customization gets turned on with it.