| Summary: | Cannot edit list permissions of a private list | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Marcel de Rooy <m.de.rooy> |
| Component: | Lists | Assignee: | Marcel de Rooy <m.de.rooy> |
| Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | fridolin.somers, jonathan.druart, m.de.rooy, mtj |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10865 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18228 |
||
| Change sponsored?: | --- | Patch complexity: | Trivial patch |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Bug Depends on: | |||
| Bug Blocks: | 18228 | ||
| Attachments: |
Bug 18214: Cannot edit list permissions of a private list
Bug 18214: Cannot edit list permissions of a private list Bug 18214: Add check for shared or public list |
||
|
Description
Marcel de Rooy
2017-03-06 08:44:25 UTC
Created attachment 60821 [details] [review] Bug 18214: Cannot edit list permissions of a private list If you have disabled the pref OpacAllowPublicListCreation, your users are not able to edit the list permissions for private/shared lists. For a private list they may only be theoretically relevant, but for a shared list they are relevant. Since we do not always know the history of a list (has it been public or shared, does it contains entries from other users) and therefore permissions are even relevant for a currently private list, we should just allow editing these permissions. Test plan: [1] Do not yet apply this patch. [2] Disable OpacAllowPublicListCreation. [3] Create a private list in OPAC. Edit the list. Verify that you do not see the permission combo boxes. [4] Apply this patch. Edit the list again. Do they appear now? Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 60822 [details] [review] Bug 18214: Cannot edit list permissions of a private list If you have disabled the pref OpacAllowPublicListCreation, your users are not able to edit the list permissions for private/shared lists. For a private list they may only be theoretically relevant, but for a shared list they are relevant. Since we do not always know the history of a list (has it been public or shared, does it contains entries from other users) and therefore permissions are even relevant for a currently private list, we should just allow editing these permissions. Test plan: [1] Do not yet apply this patch. [2] Disable OpacAllowPublicListCreation. [3] Create a private list in OPAC. Edit the list. Verify that you do not see the permission combo boxes. [4] Apply this patch. Edit the list again. Do they appear now? Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Magnus Enger <magnus@libriotech.no> Works as advertised. There is a Koha::VirtualShelf->is_shared method, should not we use it to know if the permissions must be displayed or not? (In reply to Jonathan Druart from comment #3) > There is a Koha::VirtualShelf->is_shared method, should not we use it to > know if the permissions must be displayed or not? You dont need the check, opac-shelves will already say: You do not have permission to update this list. (In reply to Jonathan Druart from comment #3) > There is a Koha::VirtualShelf->is_shared method, should not we use it to > know if the permissions must be displayed or not? And it may have been shared. Or it was a public list. So the list may contain items from other people.. Temporarily blocking this one in favor of bug 18228. That bug includes this change too, but simplifies things. We just ran into this: If OpacAllowPublicListCreation is turned off, you can't allow users to add to your shared list. This renders the sharing a bit useless :( It's especially odd since the system preference OpacAllowSharingPrivateLists talks about sharing private lists and I would expect that to enable the permission options. (In reply to Katrin Fischer from comment #7) > We just ran into this: > > If OpacAllowPublicListCreation is turned off, you can't allow users to add > to your shared list. This renders the sharing a bit useless :( > > It's especially odd since the system preference OpacAllowSharingPrivateLists > talks about sharing private lists and I would expect that to enable the > permission options. This problem is definitely solved with bug 18228. The trivial change on this report is incorporated in the larger solution on that report. *** This bug has been marked as a duplicate of bug 18228 *** I understand, but not sure if the bigger solution can be backported as it also changes behaviour. (In reply to Katrin Fischer from comment #9) > I understand, but not sure if the bigger solution can be backported as it > also changes behaviour. Reopening this bug (In reply to Jonathan Druart from comment #3) > There is a Koha::VirtualShelf->is_shared method, should not we use it to > know if the permissions must be displayed or not? On second thought, I will add a check for shared or public list here. Created attachment 64504 [details] [review] Bug 18214: Add check for shared or public list Following the idea behind bug 10865, we are only showing the permissions when the list is shared or public. Adding a simple test in opac-shelves here. Note 1: Since the owner can always add or delete entries, the permissions will not be relevant anymore for a strictly private list. Note 2: Staff view always shows the permissions. This could have been changed here too, but that change is far less urgent (bug 10865 did not touch staff view and bug 18228 will rearrange permissions anyway). Test plan: [1] Verify on OPAC that you see the permissions for a private list with shares or a public list. And you do not see them for a private list without shares. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> (In reply to Katrin Fischer from comment #9) > I understand, but not sure if the bigger solution can be backported as it > also changes behaviour. The two current patches should be easy to backport. I will rebase 18228/834. Moving these trivial patches to the RM queue now. They had enough attention now imo. Pushed to master for 17.11, thanks to everybody involved! Pushed to 17.05.x, will be in 17.05.02 These patches have been pushed to 16.11.x and will be in 16.11.10. Pushed to 16.05.x, for 16.05.15 release |