Bug 19501 - New list category to restrict specific lists to staff & hide from OPAC
Summary: New list category to restrict specific lists to staff & hide from OPAC
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Lists (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement with 41 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 34249 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-10-20 10:55 UTC by Jeremy Evans
Modified: 2024-02-13 20:58 UTC (History)
15 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Evans 2017-10-20 10:55:25 UTC
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.
Comment 1 Marcel de Rooy 2017-10-23 08:36:56 UTC
(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.
Comment 2 Kim Robbins 2019-08-08 16:37:20 UTC
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.
Comment 3 Katrin Fischer 2019-08-08 16:47:10 UTC
There is a new shared flag for patron lists... maybe we could think of something similar for lists?
Comment 4 Esther Melander 2021-10-19 16:49:42 UTC
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.
Comment 5 Alex Buckley 2021-12-23 23:00:05 UTC
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
Comment 6 Marcel de Rooy 2022-01-10 08:51:49 UTC
(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.
Comment 7 Alex Buckley 2022-01-11 08:47:27 UTC
(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
Comment 8 Marcel de Rooy 2022-01-11 12:24:33 UTC
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.
Comment 9 Alex Buckley 2022-01-14 03:43:31 UTC
(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
Comment 10 Alex Buckley 2022-01-14 03:44:14 UTC
Correction: Set it back to 'New'!
Comment 11 Katrin Fischer 2023-07-16 11:49:45 UTC
*** Bug 34249 has been marked as a duplicate of this bug. ***
Comment 12 Donna 2023-07-18 19:24:57 UTC
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.
Comment 13 Marcel de Rooy 2023-07-19 10:28:33 UTC
Just mentioning: We also have shared lists. A staff member could share a list with staff members of choice.
Comment 14 Dani Elder 2023-10-27 20:27:32 UTC
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.
Comment 15 Lucas Gass 2023-11-14 20:40:52 UTC
(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?
Comment 16 Michaela Sieber 2023-11-26 10:45:41 UTC
(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."
Comment 17 Laura Horgan 2023-12-12 16:46:37 UTC
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
Comment 18 Dani Elder 2024-01-29 16:34:50 UTC
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.