There are cases where you want library staff users to create and share lists with OPAC users, but you don't want users to be able to create *any* lists. Koha already has a syspref called OpacAllowPublicListCreation to restrict public list creation, but we also need something like OpacAllowPrivateListCreation to restrict private list creation.
I think by default we'd have to set OpacAllowPrivateListCreation to 1 because that is the status quo.
There's lots of different locations in Koha to keep in mind... - Masthead : "Lists" dropdown menu - Search results : "Select titles to: Add to...", "Save to lists" - Detail page : "Save to your lists" - Usermenu : "Lists" - Lists/Shelves : "Your lists" - Cart : "Add to a list"
- Masthead : "Lists" dropdown menu - Search results : "Select titles to: Add to...", "Save to lists" - Detail page : "Save to your lists" - Usermenu : "Lists" - Lists/Shelves : "Your lists", "Save to another list" and "Add to list" (for public lists) - Cart : "Add to a list"
- Masthead : "Lists" dropdown menu - Search results : "Select titles to: Add to...", "Save to lists" - Detail page : "Save to your lists" - Lists/Shelves : "Your lists", "Save to another list" and "Add to list" (for public lists) - Cart : "Add to a list"
(In reply to David Cook from comment #4) > - Masthead : "Lists" dropdown menu Hidden "Your > - Search results : "Select titles to: Add to...", "Save to lists" > - Detail page : "Save to your lists" > - Lists/Shelves : "Your lists", "Save to another list" and "Add to list" > (for public lists) > - Cart : "Add to a list"
(In reply to David Cook from comment #4) > - Masthead : "Lists" dropdown menu Show "New list" if OpacAllowPrivateListCreation || OpacAllowPublicListCreation > - Search results : "Add to list", "Save to lists" Show "Save to lists" if OpacAllowPrivateListCreation || OpacAllowPublicListCreation koha-tmpl/opac-tmpl/bootstrap/en/includes/title-actions-menu.inc Show "Add to list" if OpacAllowPrivateListCreation || OpacAllowPublicListCreation koha-tmpl/opac-tmpl/bootstrap/en/includes/result-batch-controls.inc > - Detail page : "Save to your lists" Show "Save to your lists" if OpacAllowPrivateListCreation || OpacAllowPublicListCreation Show new list form only if OpacAllowPrivateListCreation || OpacAllowPublicListCreation koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-addbybiblionumber.tt > - Lists/Shelves : "New list", "Your lists", "Save to another list" and "Add to list" > (for public lists) Show "Save to another list" if OpacAllowPrivateListCreation || OpacAllowPublicListCreation Show "New list" if OpacAllowPrivateListCreation || OpacAllowPublicListCreation > - Cart : "Add to a list" Show "Add to a list" if OpacAllowPrivateListCreation || OpacAllowPublicListCreation
Created attachment 179497 [details] [review] Bug 39372: Limit OPAC list creation This change adds a new system preference OpacAllowPrivateListCreation, which works with the existing system preference OpacAllowPublicListCreation, to determine when "New list", "Save to lists", "Add to list", "Save to another list", and "Add to a list" should appear. If both sysprefs are disabled, then you cannot do these actions. If one of the sysprefs is enabled, then these actions appear, but are limited to the private or public list type respective to the syspref. Test plan: 0. Apply the patch and koha-plack --restart kohadev 1. Perform the following steps using differing combinations of OpacAllowPrivateListCreation, or OpacAllowPublicListCreation, or both disabled 2. Click on Lists in masthead nav and note presence of "New list" link 3. Perform a search 4. Note the presence of "Save to lists" and "Add to list" links 5. Go to a record detail page 6. Note the presence of "Save to your lists" on the sidebar 7. Create a list 8. Go to the list 9. Note the presence of "Save to another list" and "New list" links 10. Add a record to the cart 11. Note the presence of "Add to a list" link
Database changes to follow shortly...
Created attachment 179498 [details] [review] Bug 39372: Database changes
If you already have lists belonging to you, you'll be able to edit or delete them... but you can't create new lists or add to your existing lists.
I reckon there's probably more work to do here. Lists are a bit of a mess...
I think there's a few bugs with OpacAllowPublicListCreation before this patch as well... it's not a comprehensive syspref...
Created attachment 179566 [details] [review] Bug 39372: Database changes
Is this patch ready to be signed off or does it still need work before ?
(In reply to Marion Durand from comment #14) > Is this patch ready to be signed off or does it still need work before ? It should be ready to be tested and signed off.
I tested your patch with ktd. It worked well for the following combination private don't allow; public don't allow private allow; public don't allow private allow; public allow I had a problem with the combination : private don't allow, public allow In this case, I was still able to create private lists even with the preference system on don't allow. Could you provide a follow-up to address this issue?
(In reply to Marion Durand from comment #16) > I had a problem with the combination : > private don't allow, public allow > In this case, I was still able to create private lists even with the > preference system on don't allow. > > Could you provide a follow-up to address this issue? Thanks for testing! I'll look at doing a follow-up later this week or next week.
(In reply to Marion Durand from comment #16) > I tested your patch with ktd. > > It worked well for the following combination > private don't allow; public don't allow > private allow; public don't allow > private allow; public allow > > I had a problem with the combination : > private don't allow, public allow > In this case, I was still able to create private lists even with the > preference system on don't allow. > > Could you provide a follow-up to address this issue? Sorry for the delay on this one. I think that I see the issue now. It also looks like when Public is disabled and Private is enabled, there is a "New list" that appears on the Public tab, but it actually just creates a Private list. I'll look at that too...
Changing this to enhancement like bug 39374
Created attachment 181333 [details] [review] Bug 39372: (follow-up) Fix toolbar and public/private selector On the lists page, it makes the "New list" link appear on the correct tab as per the sysprefs regarding Private/Public list creation. It also fixes the Public/Private "Category" dropdown menu when creating a new list, so that the options match the sysprefs.
Created attachment 181334 [details] [review] Bug 39372: (follow-up) Add sysprefs to controller scripts By adding the sysprefs to the controller scripts, we can prevent accidental creations or malicious creations. In theory, these error conditions shouldn't be triggered, since only the allowed actions will be displayed on the UI, but we need to cover all our bases. The error messages in opac-shelves.pl aren't currently translatable. The error handling will need some refactoring to make them translatable. However, in this particular case, it should be OK, since no one but a pen tester should bump into this message.
(In reply to Marion Durand from comment #16) > I tested your patch with ktd. > > It worked well for the following combination > private don't allow; public don't allow > private allow; public don't allow > private allow; public allow > > I had a problem with the combination : > private don't allow, public allow > In this case, I was still able to create private lists even with the > preference system on don't allow. > > Could you provide a follow-up to address this issue? Thanks again, Marion. Can you give it another go? It should be better now. Thanks!
Created attachment 181336 [details] [review] Bug 39372: Limit OPAC list creation This change adds a new system preference OpacAllowPrivateListCreation, which works with the existing system preference OpacAllowPublicListCreation, to determine when "New list", "Save to lists", "Add to list", "Save to another list", and "Add to a list" should appear. If both sysprefs are disabled, then you cannot do these actions. If one of the sysprefs is enabled, then these actions appear, but are limited to the private or public list type respective to the syspref. Test plan: 0. Apply the patch and koha-plack --restart kohadev 1. Perform the following steps using differing combinations of OpacAllowPrivateListCreation, or OpacAllowPublicListCreation, or both disabled 2. Click on Lists in masthead nav and note presence of "New list" link 3. Perform a search 4. Note the presence of "Save to lists" and "Add to list" links 5. Go to a record detail page 6. Note the presence of "Save to your lists" on the sidebar 7. Create a list 8. Go to the list 9. Note the presence of "Save to another list" and "New list" links 10. Add a record to the cart 11. Note the presence of "Add to a list" link Signed-off-by: Marion Durand <marion.durand@biblibre.com>
Created attachment 181337 [details] [review] Bug 39372: Database changes Signed-off-by: Marion Durand <marion.durand@biblibre.com>
Created attachment 181338 [details] [review] Bug 39372: (follow-up) Fix toolbar and public/private selector On the lists page, it makes the "New list" link appear on the correct tab as per the sysprefs regarding Private/Public list creation. It also fixes the Public/Private "Category" dropdown menu when creating a new list, so that the options match the sysprefs. Signed-off-by: Marion Durand <marion.durand@biblibre.com>
Created attachment 181339 [details] [review] Bug 39372: (follow-up) Add sysprefs to controller scripts By adding the sysprefs to the controller scripts, we can prevent accidental creations or malicious creations. In theory, these error conditions shouldn't be triggered, since only the allowed actions will be displayed on the UI, but we need to cover all our bases. The error messages in opac-shelves.pl aren't currently translatable. The error handling will need some refactoring to make them translatable. However, in this particular case, it should be OK, since no one but a pen tester should bump into this message. Signed-off-by: Marion Durand <marion.durand@biblibre.com>