We are creating various lists of titles that need to be hidden from view in the OPAC for the time being but other staff members need to see them. At the moment the options are Public or Private so this won't do what we require. We would like an additional list category selection of Staff so that those lists are then visible in the staff client (& presumably also to anyone who logs into the OPAC with a staff permissions login) but are not publicly visible in the OPAC. The intention is that multiple staff members may need to add items to some of these lists.
(In reply to Jeremy Evans from comment #0) > We are creating various lists of titles that need to be hidden from view in > the OPAC for the time being but other staff members need to see them. > At the moment the options are Public or Private so this won't do what we > require. We would like an additional list category selection of Staff so > that those lists are then visible in the staff client (& presumably also to > anyone who logs into the OPAC with a staff permissions login) but are not > publicly visible in the OPAC. > > The intention is that multiple staff members may need to add items to some > of these lists. Jeremy, Can you do this with the shared list feature? One member creates a list and invites other members. The creator can give them privilege to add entries to the list.
The issue we have with the way lists are "shared" is that we cannot share it from within the staff client. We have to log in to the OPAC to share the lists with our colleagues. It would be nice to be able to have it shared as we create it - or, at least, shareable from within the staff client.
There is a new shared flag for patron lists... maybe we could think of something similar for lists?
Expanding on this a bit. It would be nice to have the ability to create a list in the staff interface and then have a way to share that list with other staff members. I envision a share button that would allow you to add a staff member as a contributor with the ability to edit the list. Once shared, that list would show in the staff members account as well as the creator/manager of the list. Our current workaround is to create a special staff account for shared lists, which is inefficient because it requires logging in and out of multiple accounts to accomplish tasks.
Hi there, In bug 26346 I've added the ability to create public lists that are only editable by staff, but viewable by all. Question: Rather than add a 'Share' button in the staff client would it be the cleaner solution to revert bug 28959 , and add a third category of 'Restricted' which is viewable by all in the staff client, and by staff users in the OPAC? I'm not sure what the best practice is for reverting patches that have been upstreamed? Thanks! Alex
(In reply to Alex Buckley from comment #5) > Hi there, > > In bug 26346 I've added the ability to create public lists that are only > editable by staff, but viewable by all. > > Question: Rather than add a 'Share' button in the staff client would it be > the cleaner solution to revert bug 28959 , and add a third category of > 'Restricted' which is viewable by all in the staff client, and by staff > users in the OPAC? > > I'm not sure what the best practice is for reverting patches that have been > upstreamed? Fun, I commented on bug 28959 earlier that we were on the "wrong track" there. But Restricted is imho not directly a candidate for a new category. It sounds more like a security thing on lists. (Similarly, Shared is still no category, but a more limited implementation using private lists.) This whole thing with public lists and staff users is duplicated on several reports still, and hunts us already for years.
(In reply to Marcel de Rooy from comment #6) > (In reply to Alex Buckley from comment #5) > > Hi there, > > > > In bug 26346 I've added the ability to create public lists that are only > > editable by staff, but viewable by all. > > > > Question: Rather than add a 'Share' button in the staff client would it be > > the cleaner solution to revert bug 28959 , and add a third category of > > 'Restricted' which is viewable by all in the staff client, and by staff > > users in the OPAC? > > > > I'm not sure what the best practice is for reverting patches that have been > > upstreamed? > > Fun, I commented on bug 28959 earlier that we were on the "wrong track" > there. > But Restricted is imho not directly a candidate for a new category. It > sounds more like a security thing on lists. (Similarly, Shared is still no > category, but a more limited implementation using private lists.) > > This whole thing with public lists and staff users is duplicated on several > reports still, and hunts us already for years. Hi Marcel, Thanks for your reply. Just to make sure I'm understanding correctly, it sounds like, in your view, lists viewable to staff would be best implemented as a private list. That has a 'share' button so the user can search for, and select, those staff members they want the list visible for? Am I understanding that correctly? Thanks Alex
If I am reading the comment from Jeremy again (from 2017..) and my response in 2017, they could have used private lists shared between the needed staff members at that time already (but using OPAC) without the need for any code changes. I think there is a report about adding code for supporting shared lists in staff too. But I would certainly not oppose a permission scheme that allows selected staff members to view *some* lists. Just another road. In the past we were very cautious here in view of privacy issues though. But there should be ways to address that and inform users accordingly.
(In reply to Marcel de Rooy from comment #8) > If I am reading the comment from Jeremy again (from 2017..) and my response > in 2017, they could have used private lists shared between the needed staff > members at that time already (but using OPAC) without the need for any code > changes. > > I think there is a report about adding code for supporting shared lists in > staff too. > > But I would certainly not oppose a permission scheme that allows selected > staff members to view *some* lists. Just another road. In the past we were > very cautious here in view of privacy issues though. But there should be > ways to address that and inform users accordingly. Hi Marcel, Thanks for your reply. Yep, that makes sense. I may revisit this and try to submit a patch for it, separately from my work on bug 26346. But will leave the assignee as 'koha-bugs@lists.koha-community.org' for now and set it back to 'Assigned', in case someone else wants to work on it. Thanks, Alex
Correction: Set it back to 'New'!
*** Bug 34249 has been marked as a duplicate of this bug. ***
Just adding this in as a bump - it would be really helpful to have options! There are many cases where a list needs to be viewable to a number of staff, but not viewable in the OPAC. Currently the only way other staff members can view a list is to make it public, but this is not workable as it also shows it in the OPAC. It would be really helpful to have a third option: Public, Private, Staff. Anyone who has access to login to the staff interface should be able to view lists set as Staff.
Just mentioning: We also have shared lists. A staff member could share a list with staff members of choice.
I like the public (visible in catalog), private(only me), staff (only staff) lists options Donna mentioned. It would be nice if I could create a list for a project and share it to another staff person to do the work and add/delete/edit form the list as they complete the work without having to run a report(potentially resource intensive) each time. Ideally I would like to limit it to certain staff, but I would accept the option of all staff or none in lieu of no staff-side only list.
(In reply to Marcel de Rooy from comment #13) > Just mentioning: We also have shared lists. A staff member could share a > list with staff members of choice. They could share a public list that only staff could edit. Wouldn't this still be a publicly accessible list? Sounds like we need what Donna and Dani both mentioned: Public lists (visible everywhere) Private lists (visible by the user only ) Staff only (visible only to staff) Now would that be visible to all staff, or only staff with certain permssions?
(In reply to Lucas Gass from comment #15) > > They could share a public list that only staff could edit. Wouldn't this > still be a publicly accessible list? Sounds like we need what Donna and Dani > both mentioned: > > Public lists (visible everywhere) > Private lists (visible by the user only ) > Staff only (visible only to staff) > > Now would that be visible to all staff, or only staff with certain > permssions? I agree with Donna and Dani. I think it would be ok if lists with 'Staff only' are visible to all staff members as Donna wrote in Comment 12: "Anyone who has access to login to the staff interface should be able to view lists set as Staff."
Hi folks I work in technical services and most of my lists are for cleanup or record keeping and I would not want this information in the catalog even if the public can't change. We also have the additional issue of the owner/creator of the list who leaves and perhaps we need to transfer ownership of the lists to another staff member. Just wondering if others would have a need to change ownership of a list
Transfer of ownership would be nice so we don't have orphaned list when staff change/leave. I do wish for staff-only list view (no public view in opac) almost daily.
I have several lists that I use for staff workflows. It would be helpful if they were limited to the staff interface instead of being visible on the OPAC. These lists are confusing for patrons because they were intended for staff and clutter up the list of lists.