Re: [Koha-devel] Improving permissions on lists (virtual shelves)
Thanks all for responding to this inquiry. This was very helpful. I am merging here the results and will be posting them back to report 7310 or a wiki page. Feel free to correct me where I made the wrong conclusion. 1 Public lists in OPAC: Currently, a user should be logged in to create a list. I would strongly recommend to keep that restriction. A new preference is added that allows opac users to create public lists or does not allow that. Additionally, I would add the restriction that another opac user cannot change the list type of a public list to private list or change the list permissions when he did not create it (currently possible); the owner can do that or a staff member with permissions in the staff client. 2 Three new permissions per list: Add items, Delete own items, Delete other items. This makes the Open list type obsolete. 3 Share private lists with another patron (as described before). Can be turned on/off with a preference. 4 Staff client features: add an option under Tools to moderate inappropriate list names for public lists and shared private lists. (A library is free to use it or not.) Add staff list permission: allow to manage lists (virtual shelves). With that permission a staff member can moderate the list names as mentioned and access the staff Lists module. (He can change list type and permissions. He can take ownership of a public list if the owner has been deleted.) 5 [NEW] Deleting a patron should also delete his (unshared) private lists, his shares with private lists of someone else and clear owner on his public lists. [Currently, the virtualshelves table will contain lists (of any type) of deleted borrowers.] A new problem is what to do with shared private lists (still used by other patrons). Just deleting them would not be nice for those patrons. Just promoting them to public lists could not be ideal too; same for leaving this to be sorted out by the librarian. The best [pragmatic] solution is probably setting ownership to the first user that received a share on that list. (He already had access to those lists, but is now able to change settings on that list too.) ADDITIONAL COMMENT If a library does not allow public list creation in OPAC and does not share lists, how should a staff member change list type of a private list? This is not possible. You could say by design. It is the result of combining those two prefs. As a workaround, a staff member could enable public list creation, let the user change list type in opac and reset the pref. Or enable sharing lists, let the user share that list with staff member, accept it and reset the pref.
Hi all, In the meantime the patches under report 7310 were pushed to master. Some work still is to be done. Please have a look at bug 7805 (Exposing the new list permissions in opac and staff). This makes the changes for point 2 below visible. Would be nice (imo) to have that on top of the 7310 patches in 3.8? Point 3 and 4 are for the next version ;) Thanks, Marcel Van: Marcel de Rooy Verzonden: woensdag 7 december 2011 17:09 Aan: koha@lists.katipo.co.nz; koha-devel@lists.koha-community.org Onderwerp: RE: Improving permissions on lists (virtual shelves) Thanks all for responding to this inquiry. This was very helpful. I am merging here the results and will be posting them back to report 7310 or a wiki page. Feel free to correct me where I made the wrong conclusion. 1 Public lists in OPAC: Currently, a user should be logged in to create a list. I would strongly recommend to keep that restriction. A new preference is added that allows opac users to create public lists or does not allow that. Additionally, I would add the restriction that another opac user cannot change the list type of a public list to private list or change the list permissions when he did not create it (currently possible); the owner can do that or a staff member with permissions in the staff client. 2 Three new permissions per list: Add items, Delete own items, Delete other items. This makes the Open list type obsolete. 3 Share private lists with another patron (as described before). Can be turned on/off with a preference. 4 Staff client features: add an option under Tools to moderate inappropriate list names for public lists and shared private lists. (A library is free to use it or not.) Add staff list permission: allow to manage lists (virtual shelves). With that permission a staff member can moderate the list names as mentioned and access the staff Lists module. (He can change list type and permissions. He can take ownership of a public list if the owner has been deleted.) 5 [NEW] Deleting a patron should also delete his (unshared) private lists, his shares with private lists of someone else and clear owner on his public lists. [Currently, the virtualshelves table will contain lists (of any type) of deleted borrowers.] A new problem is what to do with shared private lists (still used by other patrons). Just deleting them would not be nice for those patrons. Just promoting them to public lists could not be ideal too; same for leaving this to be sorted out by the librarian. The best [pragmatic] solution is probably setting ownership to the first user that received a share on that list. (He already had access to those lists, but is now able to change settings on that list too.) ADDITIONAL COMMENT If a library does not allow public list creation in OPAC and does not share lists, how should a staff member change list type of a private list? This is not possible. You could say by design. It is the result of combining those two prefs. As a workaround, a staff member could enable public list creation, let the user change list type in opac and reset the pref. Or enable sharing lists, let the user share that list with staff member, accept it and reset the pref.
participants (1)
-
Marcel de Rooy