Now when Koha asks to transfer an item which is on hold it will give HoldSlip to a librarian. We have TransferSlip which is used in other transfering situations, so we should use this also when transfering hold item. The HoldSlip should trigger when the item is checked in after transfer to the right branch. Combining the hold and transfer slips might get confusing if the slip is used on self-service pickup as we are doing in Finnish public libraries. Also there comes the data protection issue if other patrons can see too much information about holds.
Created attachment 91438 [details] [review] Bug 23292: Use TransferSlip when transfering item which is on hold Combining hold and transfer slips might get confusing for patrons. Those represent quite different things. Hold slip could be used on self-service pickup for patrons and transfer slip has information for librarians. There can also be data protection issue if same slip is used in both cases. Test plan: - Apply the patch - Create hold for a record, define pickup branch different than your current branch. - Check in an item from your branch. - Click 'Print slip, transfer, and confirm' - See that the slip is TRANSFERSLIP - Change your branch same as hold's pickup branch - Check in the item again. - Click 'Print slip and confirm' - See that the slip is now HOLD_SLIP Sponsored-by: Koha-Suomi Oy
Johanna, I cannot cleanly apply this patch to master.
Created attachment 93167 [details] [review] Bug 23292: Use TransferSlip when transfering item which is on hold Now the patch should apply to master.
Created attachment 93177 [details] [review] Bug 23292: Use TransferSlip when transfering item which is on hold Combining hold and transfer slips might get confusing for patrons. Those represent quite different things. Hold slip could be used on self-service pickup for patrons and transfer slip has information for librarians. There can also be data protection issue if same slip is used in both cases. Test plan: - Apply the patch - Create hold for a record, define pickup branch different than your current branch. - Check in an item from your branch. - Click 'Print slip, transfer, and confirm' - See that the slip is TRANSFERSLIP - Change your branch same as hold's pickup branch - Check in the item again. - Click 'Print slip and confirm' - See that the slip is now HOLD_SLIP Sponsored-by: Koha-Suomi Oy Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Changing from HoldSlip to TransferSlip would be a step back for us, as we differentiate between holds and ordinary transfers - which enables us to prioritise how we unpack our stock. I think the problem described can be resolved with Template Toolkit - you can create an IF this THEN this ELSE this condition in the HoldSlip syntax. Here's an example of the syntax (which you can then modify with HTML to lay it out correctly): [% USE Branches %] [% loggedinbranchname = Branches.GetName( Branches.GetLoggedInBranchcode() ) %] [% IF loggedinbranchname == branch.branchname%] [% hold.expirationdate | $KohaDates %] [% borrower.surname %] [% USE String %] [% patronsname = borrower.firstname %] [% patronsname.substr (0, 1) %] [% USE String %] [% patronscard = borrower.cardnumber %] *******[% patronscard.substr (7, 3) %] [% branch.branchname %] [% biblio.title %] [% biblio.author %] [% item.barcode %] [% branch.branchname %] [% today | $KohaDates %] [% ELSE %] [% branch.branchcode %]* [% branch.branchname %] [% biblio.title %] [% biblio.author %] [% item.barcode %] [% today | $KohaDates %] [% END %]
Johanna, seeing Sally's comment: would it be possible to make this behavior optional? I agree that using the transfer slip seems logical to me as well, but as Koha never worked that way, libraries might not be happy about the change and there might be use cases we are missing. There is also some things missing: - You change the en installer, but you also need to add to the other installers (there is a unit test helping with that in xt I think) - Database update statement Currently your patch would only work for new English installations, need to take care of the other options as well.
I still see Johannas approach as the more valid one, especially concerning issues of data privacy. For Sallys use case, I would suggest changing the approach: adding holds information to the transfer slips using the IF statement in the TT syntax, rather than keeping todays behaviour.
(In reply to Andreas Hedström Mace from comment #7) > I still see Johannas approach as the more valid one, especially concerning > issues of data privacy. For Sallys use case, I would suggest changing the > approach: adding holds information to the transfer slips using the IF > statement in the TT syntax, rather than keeping todays behaviour. I agree with you, but while we think this is better, others might not. It will also create problems with updates and conflict with our principle of not interrupting workflows on update. - notices need to be changed and possibly translated - we can't automatically do that on update, so it would need a big warning sign That's why I have been asking for making this optional. We could keep the existing behaviour and switch it for new installations. Also - everyone who wants to, can switch as soon as things are configured. For you suggestion we'd also need to make sure that TRANSFERSLIP has access to the same tables/objects as the current HOLDSLIP.
(In reply to Katrin Fischer from comment #8): Yes, it might make most sense to make it optional. I see your point. I'm just thinking that there are so many system preferences in Koha, that new ones should be added carefully. But here it makes sense. =)
(In reply to Andreas Hedström Mace from comment #7) > I still see Johannas approach as the more valid one, especially concerning > issues of data privacy. For Sallys use case, I would suggest changing the > approach: adding holds information to the transfer slips using the IF > statement in the TT syntax, rather than keeping todays behaviour. Thanks Katrin - making it optional would be a good solution. Andreas - as long as our workflow can remain the same (it is vital that staff packing and unpacking items in transit can differentiate on the printed slip between low and high priority transfers - i.e. ordinary returns vs items on hold), I don't mind how we approach this. ...but I can't see how to implement your suggestion of using TransferSlip instead of HoldSlip? The two notices don't share the same object variables - hold and borrower aren't available in TransferSlip, so how would we identify something as being on hold?
(In reply to Sally from comment #10) > ...but I can't see how to implement your suggestion of using TransferSlip > instead of HoldSlip? The two notices don't share the same object variables > - hold and borrower aren't available in TransferSlip, so how would we > identify something as being on hold? I had missed that those objects aren't available for the transfer-slip. So making the new bahviour optional as Katrin suggest makes more sense than adding more objects to the transfer slips.
Ok, I will make this optional and looking those other things mentioned.