Bug 20718

Summary: Add ability to have lists that are available to all list editors
Product: Koha Reporter: Kyle M Hall <kyle>
Component: ToolsAssignee: Kyle M Hall <kyle>
Status: RESOLVED MOVED QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: alexbuckley, andrewfh, bibliwho, christian.stelzenmueller, dilan, dschust1, fiona.borthwick, wizzyrea
Version: master   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26346
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Bug 20718 - Add ability to have lists that are available to all list editors
Bug 20718 - Add ability to have lists that are available to all list editors
Bug 20718: Add missing POD
Bug 20718 - Add ability to have lists that are available to all list editors
Bug 20718: Add missing POD
Bug 20718: Add ability to have lists that are available to all list editors
Bug 20718: Add ability to have lists that are available to all list editors
Bug 20718: Set owner to NULL when owner is deleted

Description Kyle M Hall 2018-05-07 12:03:12 UTC
Some librarians would like to have lists that can be shared among staff that have the lists permission.

Test Plan:
1) Apply this patch
2) Create some private, public and 'staff' lists
3) Note only staff that can edit lists have access to the 'staff' lists
Comment 1 Kyle M Hall 2018-05-07 12:29:35 UTC Comment hidden (obsolete)
Comment 2 Dilan Johnpullé 2018-05-09 01:06:30 UTC
Applied patch, created some lists including 'staff' but noticed that 'staff' lists seemingly vanish after creation.

/cgi-bin/koha/virtualshelves/shelves.pl only shows private and public lists; all staff lists are invisible to the owner and anyone else.
Comment 3 Kyle M Hall 2018-05-09 11:25:17 UTC
Created attachment 75201 [details] [review]
Bug 20718 - Add ability to have lists that are available to all list editors

Some librarians would like to have lists that can be shared among staff that have the lists permission.

Test Plan:
1) Apply this patch
2) Create some private, public and 'staff' lists
3) Note only staff that can edit lists have access to the 'staff' lists
Comment 4 Kyle M Hall 2018-05-09 11:26:10 UTC
(In reply to Dilan Johnpullé from comment #2)
> Applied patch, created some lists including 'staff' but noticed that 'staff'
> lists seemingly vanish after creation.
> 
> /cgi-bin/koha/virtualshelves/shelves.pl only shows private and public lists;
> all staff lists are invisible to the owner and anyone else.

Should be fixed now! Please try again!
Comment 5 Owen Leonard 2018-07-02 18:07:50 UTC
I find that my staff user can see the list created by another staff member and edit it, but can't view it. When trying to view it I get an incorrectly-styled dialog, "You do not have permission to view this list."

Also, the 'delete' button appears but doesn't work.

Should I be able to add to a staff list if I have the correct permission? The staff lists are not available in the "Add to list" window triggered from the biblio detail page.

One QA tool failure:

 FAIL   Koha/Virtualshelf.pm
   OK     critic
   OK     forbidden patterns
   OK     git manipulation
   OK     pod
   FAIL   pod coverage
                POD is missing for is_staff
   OK     spelling
   OK     valid
Comment 6 Kyle M Hall 2018-07-13 10:55:29 UTC
Created attachment 76944 [details] [review]
Bug 20718: Add missing POD
Comment 7 Cab Vinton 2018-08-18 00:41:26 UTC
Tried applying the patch to several sandboxes, but without success.

<h1>Something went wrong !</h1>Applying: Bug 20718 - Add ability to have lists that are available to all list editors
Using index info to reconstruct a base tree...
M       koha-tmpl/intranet-tmpl/prog/en/modules/virtualshelves/shelves.tt
Falling back to patching base and 3-way merge...
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/virtualshelves/shelves.tt
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/virtualshelves/shelves.tt
error: Failed to merge in the changes.
Patch failed at 0001 Bug 20718 - Add ability to have lists that are available to all list editors
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem run git bz apply --continue.
If you would prefer to skip this patch, instead run git bz apply --skip.
To restore the original branch and stop patching run git bz apply --abort.
Bug 20718 - Add ability to have lists that are available to all list editors

75201 - Bug 20718 - Add ability to have lists that are available to all list editors
76944 - Bug 20718: Add missing POD

Apply? [(y)es, (n)o, (i)nteractive] Patch left in /tmp/Bug-20718---Add-ability-to-have-lists-that-are-ava-4FEpmq.patch .
Comment 8 Kyle M Hall 2018-10-25 12:23:04 UTC
Created attachment 81135 [details] [review]
Bug 20718 - Add ability to have lists that are available to all list editors

Some librarians would like to have lists that can be shared among staff that have the lists permission.

Test Plan:
1) Apply this patch
2) Create some private, public and 'staff' lists
3) Note only staff that can edit lists have access to the 'staff' lists
Comment 9 Kyle M Hall 2018-10-25 12:23:15 UTC
Created attachment 81136 [details] [review]
Bug 20718: Add missing POD
Comment 10 Alex Buckley 2018-10-29 00:29:22 UTC
Hi Kyle

Sorry I am finding what Owen described in comment 5 which is when other staff members try to view staff lists they see a "You do not have permission to view this list" message. This is displayed even though the staff member has 'list' permission.

I'll be keen to keep testing after this is fixed, or if this is the correct behavior could you please note that. 

Cheers,
Alex
Comment 11 Liz Rea 2019-03-28 17:50:24 UTC
Another thing I noticed was that I couldn't seem to create a list from the search results for a "staff list," only "public" and "private" were options. It seems like that should work?

Cheers,
Liz
Comment 12 Liz Rea 2019-03-28 17:51:18 UTC
(Should add, I was doing this in the staff side, not the OPAC. I wouldn't expect staff lists to be creatable from the OPAC unless it was a staff member logged in and even that's a stretch.)
Comment 13 Katrin Fischer 2019-05-04 15:10:33 UTC
*** Bug 3335 has been marked as a duplicate of this bug. ***
Comment 14 Kyle M Hall 2021-01-26 14:14:45 UTC
Created attachment 115823 [details] [review]
Bug 20718: Add ability to have lists that are available to all list editors

Some librarians would like to have lists that can be shared among staff that have the lists permission.

Test Plan:
1) Apply this patch
2) Create some private, public and 'staff' lists
3) Note only staff that can edit lists have access to the 'staff' lists
Comment 15 PTFS Europe Sandboxes 2021-02-11 13:29:36 UTC
Created attachment 116716 [details] [review]
Bug 20718: Add ability to have lists that are available to all list editors

Some librarians would like to have lists that can be shared among staff that have the lists permission.

Test Plan:
1) Apply this patch
2) Create some private, public and 'staff' lists
3) Note only staff that can edit lists have access to the 'staff' lists

Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de>
Comment 16 Katrin Fischer 2021-03-12 10:02:30 UTC
Hi Kyle,

are staff lists private (only visible in staff) or are they public (visible in the OPAC as well)?

I am wondering if the option is in the right field or should not be a checkbox.  Maybe if we leave it in the pulldown, we could change it up a little so it's clear what will happen.

Does the staff type affect what happens when the list is deleted? Is the list still tied to the owner or is the type enough and borrowernumber could be NULLed?

Very much in favor of this feature :)
Comment 17 Kyle M Hall 2021-03-12 10:57:19 UTC
(In reply to Katrin Fischer from comment #16)
> Hi Kyle,
> 
> are staff lists private (only visible in staff) or are they public (visible
> in the OPAC as well)?

They are private, available only to staff.

> I am wondering if the option is in the right field or should not be a
> checkbox.  Maybe if we leave it in the pulldown, we could change it up a
> little so it's clear what will happen.

I don't see any problem with that, but it would add a lot of complication to the code and require altering the database schema which I've tried to avoid doing.
 
> Does the staff type affect what happens when the list is deleted? Is the
> list still tied to the owner or is the type enough and borrowernumber could
> be NULLed?

If the owning staff member is deleted, the list is deleted. I see no reason that we could not null the owner!
Comment 18 Kyle M Hall 2021-03-12 11:08:00 UTC
Created attachment 118185 [details] [review]
Bug 20718: Set owner to NULL when owner is deleted
Comment 19 Andrew Fuerste-Henry 2021-06-16 11:48:55 UTC
Bug 26346 has an alternate approach for this, adding a new option of "staff only" for editing so a public list can be set to be editable by just the owner, just staff, or everyone. I prefer that more granular control.
Comment 20 Kyle M Hall 2021-06-17 12:30:30 UTC
(In reply to Andrew Fuerste-Henry from comment #19)
> Bug 26346 has an alternate approach for this, adding a new option of "staff
> only" for editing so a public list can be set to be editable by just the
> owner, just staff, or everyone. I prefer that more granular control.

Sounds good! Let's close this one for now. It something goes awry with 26346 this can always be resurrected!