At the moment the virtualshelves system parameter is an ON/OFF option. I think this needs to be more granular: - no lists - lists for staff only (= virtualshelves OFF now) - allow patrons to create private lists - allow patrons to create private and public lists (= virtuelshelves ON now) Good or bad idea? Do we need more than that?
Those sound like very reasonable permissions to me.
Should patrons be allowed to contribute to Open lists? Or create them?
*** Bug 2037 has been marked as a duplicate of this bug. ***
It might be useful to be able to let some patron categories create/edit lists and others not. I'm thinking of e.g. schools that might want to let all teachers create lists, but not the pupils.
*** Bug 4253 has been marked as a duplicate of this bug. ***
It looks like most of the issues mentioned on this report have been dealt with in the meantime. If virtualshelves is off, opac users have no lists. Imo this pref could be an opac pref, why not allow staff users always to create lists? If the pref is off, a public list is only partially visible on staff side. I think we should just enable the functionality in staff "everywhere"; if you do not use it, no problem. If virtualshelves is on, we can now control the creation of public lists by opac users with a specific pref. Patrons can create private lists. Sharing lists (bug 9032) is controlled by another pref. The permissions per list allow you to control adding items or not. Comment4 of Magnus remains. Probably we could turn this into: Control the creation of public lists per user category instead of the generic pref. I would suggest to open a new report for that one, if it is really needed. Comments welcome.
Hi Marcel, I had started to work on this, lost my branch, got lost in the logic of the virtualshelves code and never got to return to it :( I think having a fresh start with a new bug describing exactly the now needed changes would be good.