With bug 13417 a new permission was added to allow/disallow deletion of public lists. The lists permission doesn't work like other module level permissions as turning it off won't disallow use of the lists module. It would be nice if this could be added. It might need a 'remaining lists permissions' permission, so that you can only disallow the deletion of public lists but allow general use of the module.
I agree!
I'm documenting this now and find it very confusing to users. I'd love to see this fixed for 3.20. Nicole
I would like to bump this, as turning off lists permissions for a staff user doesn't seem to stop the lists button from appearing on the home page, or stop the user from accessing and managing lists. Has this bug been forgotten about?
(In reply to Andrew Auld from comment #3) > I would like to bump this, as turning off lists permissions for a staff user > doesn't seem to stop the lists button from appearing on the home page, or > stop the user from accessing and managing lists. > > Has this bug been forgotten about? I think it's just not "annoying enough" unfortunately.
Created attachment 168384 [details] [review] Bug 30411: Put shelving location into its own column in holds queue To test: 1. Put some items on hold, make some bib level holds and some item level holds. Make sure that some of the holds have different shelving locations. 2. Build the holds queue. In KTD: perl /kohadevbox/koha/misc/cronjobs/holds/build_holds_queue.pl 3. Notice that the shelving location is in the same column as itemcallnumber 4. Apply patch and restart_all 5. Reload the holds queue and notice that shelving location now has it's own column. 6. Make sure you can sort by shelving location correctly. 7. Re-run the holds queue and apply the filter for shelving location. Make sure all your holds of that shelving location are shown. 8. While in the holds queue try usiong the 'Shelving location' filter on the left side of the page, make sure it works right. 9. Go to Admin > Table settings. Try hiding the shelving location column and reload the holds queue to make sure it is properly hidden. 10. Try hiding some other columns via Table settings to make sure all columns are still properly being hid. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Created attachment 168385 [details] [review] Bug 13888: 'Lists' permission should allow/disallow using the lists module in staff This patch adds two new system preferences, use public lists, and create public lists. Use public lists determines if a librarian is permitted to see public lists, whilst create public lists determines if a librarian can create new public lists. It also fixes erroneously allowing staff to add items to existing lists, by honouring the existing edit_public_list_contents To test: a) notice the new my lists link on the account pulldown 1) ensure it goes to the lists module b) create new public list, add at least one item, make it editable by everyone 1) note the name of the list c) create a new patron with full access to the staff client minus lists permissions d) log in as the newly created patron e) notice the lists button is missing from the staff client mainpage f) set any of the lists permissions except create public lists, use public lists, edit public list contents g) notice how the lists button is no longer missing from the staff client mainpage h) go to the lists module 1) notice that public lists are now missing from the datatable i) click add list 1) notice that the public drop-down is now a fixed label set to private j) create list and confirm it is not public k) turn use public lists permission on l) return to the lists module 1) notice that the datatable now shows private and public lists tabs m) turn create public lists permission on n) repeat steps h-i 1) notice that the public drop-down is now visible again o) create list and confirm it is public p) go to the list you created in step b q) notice that add items button, and remove selected button, is missing r) turn edit public list contents permission on s) repeat steps p-q 1) notice that add items button is now visible t) click add items u) enter an item barcode or biblio number, click save 1) notice that the items are now added to the list
Created attachment 168386 [details] [review] Tidy Koha/Virtualshelf.pm
Sorry about the woeful git bz foo, still getting the hang of things here in my new role! Thanks in advance for the sign-off :-)
Created attachment 168422 [details] [review] Bug 13888: Tidy Koha/Virtualshelf.pm
Code all looks sane and sensible to me and I think this makes a lot of sense UX wise. Adding a few people to CC list to try and drum up some user testing please.
Tested and works as described except b) and o) -- adding new list creates private list despite "Public" was selected at the creating form.
Thanks for looking, Roman. I just tried with a fresh k.t.d, and it didn't work initially. After I ran updatedatabase, it worked fine. Can I ask you kindly to try again, making sure all the atomicupdates have run?
(In reply to Jake Deery from comment #12) > Thanks for looking, Roman. I just tried with a fresh k.t.d, and it didn't > work initially. After I ran updatedatabase, it worked fine. > > Can I ask you kindly to try again, making sure all the atomicupdates have > run? I've tried again, but had the same effect. I'm not sure doing it weel, so paste listind at the end of this reply. But there is sth interesting in virtualshelves/shelves.pl: # this check is for the create list permission $allow_create_public_lists = haspermission( $loggedinuser, { lists => 'create_public_lists' } ) ? 1 : 0; # we want the user to be able to pick if public or private only if they are allowed $public = ( $query->param('public') == 1 && $allow_create_public_lists == 1 ) ? 1 : 0; haspermission need userid as first argument, but now it is $loggedinuser (second argument returned from get_template_and_user). So $allow_create_public_lists is always 0 and $public too 0. After replacing $loggedinuser by C4::Context->userenv->{id} it works. Listing: kohadev-koha@kohadevbox:koha(main)$ git checkout -b bug_13888 origin/main branch 'bug_13888' set up to track 'origin/main'. Switched to a new branch 'bug_13888' kohadev-koha@kohadevbox:koha(bug_13888)$ git bz apply 13888 Bug 13888 - 'Lists' permission should allow/disallow using the lists module in staff 168385 - Bug 13888: 'Lists' permission should allow/disallow using the lists module in staff 168422 - Bug 13888: Tidy Koha/Virtualshelf.pm Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 13888: 'Lists' permission should allow/disallow using the lists module in staff Applying: Bug 13888: Tidy Koha/Virtualshelf.pm kohadev-koha@kohadevbox:koha(bug_13888)$ perl installer/data/mysql/updatedatabase.pl DEV atomic update /kohadevbox/koha/installer/data/mysql/atomicupdate/bug_13888-Add-extra-list-perms.pl [18:05:02]: Bug 13888 - 'Lists' permission should allow/disallow using the lists module in staff Added permission 'use_public_lists' Added permission 'create_public_lists' kohadev-koha@kohadevbox:koha(bug_13888)$
Created attachment 168693 [details] [review] Bug 13888: (follow-up) fix for create_public_lists
Hello Roman, Thanks for the nice spot, I could reproduce it after trying further! I've changed to using the C4::Context method, and now the test plan seems to work as expected, with the public bool being set correctly when required. Could I kindly ask you reattempt sign off, when you have the time? Many thanks, Jake
Created attachment 168756 [details] [review] Bug 13888: 'Lists' permission should allow/disallow using the lists module in staff This patch adds two new system preferences, use public lists, and create public lists. Use public lists determines if a librarian is permitted to see public lists, whilst create public lists determines if a librarian can create new public lists. It also fixes erroneously allowing staff to add items to existing lists, by honouring the existing edit_public_list_contents To test: a) notice the new my lists link on the account pulldown 1) ensure it goes to the lists module b) create new public list, add at least one item, make it editable by everyone 1) note the name of the list c) create a new patron with full access to the staff client minus lists permissions d) log in as the newly created patron e) notice the lists button is missing from the staff client mainpage f) set any of the lists permissions except create public lists, use public lists, edit public list contents g) notice how the lists button is no longer missing from the staff client mainpage h) go to the lists module 1) notice that public lists are now missing from the datatable i) click add list 1) notice that the public drop-down is now a fixed label set to private j) create list and confirm it is not public k) turn use public lists permission on l) return to the lists module 1) notice that the datatable now shows private and public lists tabs m) turn create public lists permission on n) repeat steps h-i 1) notice that the public drop-down is now visible again o) create list and confirm it is public p) go to the list you created in step b q) notice that add items button, and remove selected button, is missing r) turn edit public list contents permission on s) repeat steps p-q 1) notice that add items button is now visible t) click add items u) enter an item barcode or biblio number, click save 1) notice that the items are now added to the list Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Created attachment 168757 [details] [review] Bug 13888: Tidy Koha/Virtualshelf.pm Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Created attachment 168758 [details] [review] Bug 13888: (follow-up) fix for create_public_lists Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Created attachment 169195 [details] [review] Bug 13888: 'Lists' permission should allow/disallow using the lists module in staff This patch adds two new system preferences, use public lists, and create public lists. Use public lists determines if a librarian is permitted to see public lists, whilst create public lists determines if a librarian can create new public lists. It also fixes erroneously allowing staff to add items to existing lists, by honouring the existing edit_public_list_contents To test: a) notice the new my lists link on the account pulldown 1) ensure it goes to the lists module b) create new public list, add at least one item, make it editable by everyone 1) note the name of the list c) create a new patron with full access to the staff client minus lists permissions d) log in as the newly created patron e) notice the lists button is missing from the staff client mainpage f) set any of the lists permissions except create public lists, use public lists, edit public list contents g) notice how the lists button is no longer missing from the staff client mainpage h) go to the lists module 1) notice that public lists are now missing from the datatable i) click add list 1) notice that the public drop-down is now a fixed label set to private j) create list and confirm it is not public k) turn use public lists permission on l) return to the lists module 1) notice that the datatable now shows private and public lists tabs m) turn create public lists permission on n) repeat steps h-i 1) notice that the public drop-down is now visible again o) create list and confirm it is public p) go to the list you created in step b q) notice that add items button, and remove selected button, is missing r) turn edit public list contents permission on s) repeat steps p-q 1) notice that add items button is now visible t) click add items u) enter an item barcode or biblio number, click save 1) notice that the items are now added to the list Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 169196 [details] [review] Bug 13888: Tidy Koha/Virtualshelf.pm Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 169197 [details] [review] Bug 13888: (follow-up) fix for create_public_lists Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Thanks for all the hard work! Pushed to main for the next 24.11.00 release as RM Assistant
The patches here modify the signature for can_biblios_be_added and we're now failing tests in Jenkins.
Created attachment 169394 [details] [review] Bug 13888: (follow-up) fix tests for Virtualshelves This patch fixes failing tests resulting from oversight in the previous attachments I supplied to this bug number.
Follow-up pushed, thanks Jake
I would push this for 24.05.x but tests fail for me on that version.
This seems like an enhancement, no 24.05.x backport unless requested.