https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38291
--- Comment #38 from David Cook <[email protected]> --- (In reply to Andrew Fuerste-Henry from comment #32) Sorry I missed this comment. Reading through it now... > I'd argue that the permission to list library groups is equivalent to the > ability to list libraries. The API route to list libraries only requires > basic catalogue permission, matching what's used for listing library groups. I'd bring your attention to the 1st patch here that doesn't just list library groups, but rather shows you parent_id, branchcode, title, description, ft_hide_patron_info, ft_limit_item_editing, ft_search_groups_opac, ft_search_groups_staff, ft_local_hold_group, and ft_local_float_group. A lot of that information should only be privy to someone with "manage_libraries" permissions. > There is no page in the staff interface to simply view a list of all > branches if one does not have admin permissions, but numerous places need to > provide the user that list in the course of other functionality (editing > patrons, items, etc). There is not yet any place in the Koha UI where a user > selects from a list of library groups, but this route is used to create one. > Bug 42625 allows record sources to be tied to library groups and allow users > from that group to edit locked records from that source. Thanks for this example. For this use case, you really just need a list of library groups including their title and description. (And really it should just be a list of libraries/library groups that the user calling the API endpoint is allowed to see. At this point, I don't think we restrict any views of that even with IndependentBranches, but I suspect one day we will want that.) To date in Koha we've been overly obsessed with the idea of a REST API to the detriment of performance and security. > (Elsewhere we manage similar group-aware access restrictions by asking the > user to limit to a specific library and then allowing that to imply access > to other libraries based on groups -- see the reports limits by library > group introduced in Bug 42621. That avoids this question of making a list of > groups visible to the user, but is arguably less clear for the user.) As I said in my other comment, I don't think other parts of Koha are good examples to point to. We have *a lot* of work to do to handle authorization consistently/well in Koha. -- Going back to the features... consider this. For this particular use case, there's no specific feature, so you probably would want something like "list/all". For listing the library groups for OPAC search groups, it should be something like "list/search_groups_opac", so that the API outputs the actual resource needed by the system, rather than the database model. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
