This report is a followup for bug 9032. It will handle accepting the invitation when the patron clicks on the link in the invitation email. But it will also take care of some futher needed adjustments: Showing the type Shared in the private lists overview. Handling the deletion of a shared list (on both sides: owner and sharer). And maybe a little code housekeeping on the way..
Housekeeping thing to do: Adjustment for _CheckShelfName? What to do with patron A that receives a share from B and a share from C but incidentally these two private lists have the same name. Or should we just allow duplicate names for lists? This will make life not easier in the current popups for adding items..
Created attachment 19602 [details] [review] Bug 10389: Share a list (part 2: accept the invitation) What it does: Test plan:
This patch only shows that there is still progress here.. Still needs some attention though. Not ready for signoff yet.
Created attachment 20033 [details] [review] Bug 10389: Share a list (part 2: accept the invitation) What it does: As a followup on report 9032 where you can send an invitation to share a private list, this report handles the response by the invited person. If he accepts this share, the private list of the sender will be shown under Your lists on the shelves page. In OPAC 'Your private lists' has been renamed to Your lists (just as in Staff). The Type column shows Private or Shared for these lists; a list appears as Shared as soon as an invitation has been accepted. The owner has the options to Edit, Delete or Share; the invited person does not have these options on the shared list. Test plan: Enable pref OpacAllowSharingPrivateLists user 1 creates new private list P1, perms: D-A-D, adds 2 items, sends share user 1 checks your lists display in opac or staff: P1 shows Private with options user 2 accepts share: sees P1, but cannot add or delete items user 2 checks your lists display again: P1 shows Shared without options user 1 checks your lists display again: P1 shows Shared with options user 2 tries to accept share again: should fail now user 3 tries to accept share: should also fail user 3 tries again, modifies shelfnumber and/or key in url: should also fail user 2 creates new private list P2, perms: A-A-A, no items, sends share user 2 checks your lists display: P2 shows Private with options user 1 accepts, adds one item user 1 checks your lists display: P2 shows Shared without options user 2 checks your lists display: P2 shows Shared with options user 2 deletes item of user 1 (allowed) user 2 deletes list P2 user 1 checks your lists display in opac or staff: P2 is gone Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 20034 [details] [review] Bug 10389: Add unit tests for AcceptShare and IsSharedList The first patch of bug 10389 adds two new routines to VirtualShelves.pm. This patch adds unit tests for them. Test plan: Run unit test t/db_dependent/VirtualShelves.t. Do all 95 tests pass? Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 20038 [details] [review] Bug 10389: Remove an accepted share If a user accepted a share, this patch allows him to remove it again. A new routine is added to VirtualShelves.pm. The Remove Share button is visible on OPAC when viewing Your lists or a particular shared list. Test plan: User 1 creates private list P3, sends a share. User 1 creates private list P4, adds one item, sends a share. User 2 accepts the share for P3. User 2 checks the shelves display, and removes share P3. User 2 accepts the share for P4. User 2 views shelf P4 with one item and confirms Remove share on that form. User 2 checks shelves display again. Run the adjusted test unit too. Did all 96 tests pass? Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Together with bug 9032, I think these patches are Koha-ready imo. You can share lists, remove the shares and end sharing by deleting the list. Note that I did omit adding the share/accept functions on the staff side, just viewing it as an opac function (like others?). But if really wanted or needed, a similar staff script can be added later on. Without blocking this report too, I still plan adding the option to optionally disown instead of delete a shared or public list. (The owner wants to get rid of the list, but the other users may still like it.) That report will come with some functionality too to handle the lists without owner at staff side (including permissions). Another remaining item to discuss and perhaps handle on a new report, would be handling name clashes. See Comment 1. For now, please help with sign-off or QA..
Applying: Bug 10389: Share a list (part 2: accept the invitation) Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Bug 10389: Share a list (part 2: accept the invitation) The copy of the patch that failed is found in: /home/christopher/git/koha/.git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
I will move this code to bug 9032. Close this report now.