IRC log for #koha, 2021-06-07

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
02:31 dcook @later tell nugged take a look at bug 28519 as well
02:31 huginn dcook: The operation succeeded.
02:31 dcook bug 28519
02:31 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=28519 enhancement, P5 - low, ---, dcook, Needs Signoff , Add a 2nd directory for Perl modules
02:31 dcook I've been wanting to do something like that for ages
05:03 chriss joined #koha
05:58 magnuse joined #koha
06:13 paxed $ grep remove_guarantors misc/cronjobs/update_patrons_category.pl
06:13 my $remove_guarantors = 0;
06:13 hmmm yes, useful.
06:14 cait joined #koha
06:15 cait1 joined #koha
06:28 cait1 kidclamp: khall: bywater solutions demo is down
06:28 https://catalog.bywatersolutions.com/
06:29 magnuse \o/
06:35 reiveune joined #koha
06:35 reiveune hello
06:40 lds joined #koha
06:40 * dcook waves
06:44 fridolin joined #koha
06:45 fridolin hi
06:52 cait joined #koha
06:53 cait1 ... and hi #koha :)
06:53 fridolin: biblibre demo is the oldest version right now - any change in sight?
06:53 Nemo_bis Oh, saw some Koha promotion going strong on social media :) https://www.kiwi.fi/pages/view[…]?pageId=223543412
06:53 alex_a joined #koha
06:54 alex_a Bonjour
06:54 cait1 Nemo_bis: hope Google translate can cope :)
06:55 fridolin cait1: ohhh we will soon update to 20.11.06, thanks for the alert
06:56 cait1 just let me know or update the demo page yourself - i usually do it once a month (hence the comments today)
06:56 sophie_m joined #koha
06:56 cait1 we have one 21.05 already frm Admin_Kuhn++
06:57 fridolin1 joined #koha
06:57 cait1 fridolin are you imitating me? :)
06:57 dcook I'll probably be doing a 21.05 soon, although planning to wait until 21.05.01...
06:58 cait1 dcook: if you have a public demo, I'll be happy to add it to the website
06:58 dcook Ah, this is for a particular library, so no demo
06:59 We'll be doing the seemingly typical thing of just doing XX.11 releases
06:59 seemingly typical vendor thing*
07:01 paxed just in case it isn't clear from that wiki.fi page, in finland all marc data in koha libraries is centrally catalogued
07:03 data comes from vendors to koha Täti database, from there to local koha installations. only specific local data is locally catalogued (eg. objects)
07:06 cait1 paxed: it's really interesting as I think our models might be similar
07:06 does centrally mean one institution does all the cataloguing or is it a cooperative model?
07:07 sophie_m joined #koha
07:08 paxed cait1: co-op
07:11 cait1 paxed: nice :)
07:12 are you doing changes in the ILS and uploading or updating in the central database and downloading? (I think the latter)
07:14 700 more libraies listed on hea since last month too :) up to 13822
07:19 paxed cait1: the latter, yes
07:21 Joubu joined #koha
07:22 Joubu thx dcook for bug 28519
07:22 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=28519 enhancement, P5 - low, ---, dcook, Needs Signoff , Add a 2nd directory for Perl modules
07:27 paul_p joined #koha
07:29 nlegrand joined #koha
07:29 nlegrand Bonjour #koha !
08:19 magnuse kia ora nlegrand
08:24 nlegrand o/ magnuse
08:27 cait joined #koha
08:28 cait2 joined #koha
08:30 ashimema morning #koha
08:33 looks like I have lots of catching up to do..
08:38 alex_a joined #koha
08:48 kohaputti joined #koha
08:49 kohaputti ashimema, hi! Seems like bug 12362 caused a little regression. When you cancel a hold in transit it doesn't show anymore as in transit on the item page. In the DB we have then http://paste.debian.net/plain/1200245
08:49 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=12362 normal, P5 - low, ---, martin.renvoize, Pushed to master , Branch transfer records orphaned on cancelled holds
08:50 kohaputti Seems like after that bug the logic was changed so that we create a new transfer *request* which doesn't have a item.transfertwhen / datesend yet registered and in the detail.pl page we only show those
08:50 ashimema, I noticed you have quite a bunch of related bugs you're working on so maybe one of them already has a fix for this?
08:53 ashimema good catch.. I'm just on catch up mode at the minute having been out for a week..
08:53 I'll stick investigating that at the top of the pile..
08:54 the cancel stuff turned into a bit of a pain in the end.. I think i jumped a bit too quick initially :(.
08:54 as you say.. it may well be fixed by another bug I've been working on.. but I couldn't point out which one yet ;)
08:55 kohaputti I'd say it is quite bad, maybe even critical regression for 20.05, the transfers state is quite hidden now and might lead to librarians giving misleading info about an item's availability
08:55 21.05
08:55 ashimema I agree
08:55 kohaputti I'm also trying work on a fix for this right now, do we have a bug report already?
08:57 ashimema ah, I see what you mean now..
08:57 don't think there's a bug yet reported for this exact bit
08:57 kohaputti I will create one right away then
08:57 ashimema pretty sure none of my other work fixes this
08:57 kohaputti I'm putting this as critical, sounds good?
08:57 ashimema I think detail.pl needs adapting to understand 'TransferCancellation'
08:58 yeah, sounds good
08:58 you say you're looking into it right now.. are you happy continuing or would you like to pass the baton and get me to look at it?
08:58 kohaputti ashimema, I'm happy if we both look into this
08:58 * ashimema could spend some time today... once my morning meeting is out of the way.
08:58 ashimema brill
08:58 kohaputti no guarantees I will understand this new system
08:58 ashimema lets both attack it then :)
09:04 davidnind joined #koha
09:11 kohaputti ashimema, hmm, why have frombranch populated btw for TransferCancellation
09:12 ashimema, anyway, I'm unsure how to accept this transfer request so ... maybe it gets changed at some point
09:12 ashimema so.. you should only get this type of transfer if you cancel a transfer whilst it's 'in transit'
09:13 so.. checking it in to the middle library should trigger the 'transfer back to' prompt
09:13 I'll have a dig.. juggling a meeting at the minute I'm afraid.
09:14 the frombranch being populated.. that feels a little odd.. I'm less sure of that
09:20 kohaputti yes it does bring that pop-up on check-in, though seems like the transit datesent doesn't get updated
09:41 petrova joined #koha
09:51 ashimema hmm
09:52 confirming (either with 'Yes' or 'Yes, Print slip') should set datesent :(
09:52 I just got out of my call
09:52 have to fix the sandboxes for a demo, then will jump on this
10:05 got a bug number for your newly created bug kohaputti?
10:05 kohaputti bug 28520
10:05 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=28520 critical, P5 - low, ---, koha-bugs, NEW , Cancelling a hold that is in transit hides item's transit status
10:05 ashimema ta
10:24 cait2 paxed: sorry if i missed your reply - technical issues with the laptop earlier
10:34 * cait2 read back now
10:39 khall joined #koha
10:49 kohaputti ashimema, I now notice that also the check after this change in Koha::Item::Transfer->in_transit is not right. The cancelled transfer has been in transit and just by merely cancelling the hold shouldn't make it non-transit state but now because there is no datesent it is not in transit
10:49 khall_ joined #koha
10:56 kohaputti ashimema, I might have explained in a difficult way: I mean cancelling hold shouldn't empty the datesent because if datesent is null then the is_transit check returns false.
10:58 ashimema, hmm, maybe is_transit should then also check whether reason == TransferCancellation
11:03 ashimema I know exactly what you mean
11:03 I'm digging through now
11:03 in effect it's the cancelled trnasfer that's still 'in_transit'
11:04 the new one, 'TransferCallellation' isn't actually in transit yet.. transit will only get triggered upon checkin of the prior transfer
11:04 ack
11:08 crap, 24434 didn't get it
11:08 * crap, 24434 didn't get in
11:12 right..
11:12 24434 is the big one here kohaputti..
11:12 I think it resolves most of it.
11:12 I'm just trying to get my head back into it..
11:13 davidnind left #koha
11:24 oleonard Hi all
11:40 ashimema kohaputti, do you think you would have a moment to look at bug 27064
11:40 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=27064 normal, P5 - low, ---, nick, Signed Off , Transferring an item with a hold allows the user to set a hold waiting without transferring to the correct branch
11:40 ashimema it's mixed up in all this and I think is also fairly critical
11:40 problem I'm having is keeping track of the set of bugs as a whole now..
11:41 getting one off the pile would help my brain ;)
11:58 kohaputti ashimema, I'm checking
12:00 sophie_m joined #koha
12:01 paul_p joined #koha
12:08 kohaputti ashimema, for availability showing purposes on opac the new 'TransferCallellation' should be somehow listed as in transit, otherwise the patron thinks it is available at the library
12:08 ashimema, but continuing now on 27064 ...
12:21 ashimema Yes, I'm working on that part now
12:22 in short, I believe we need to switch to 'get_transfers' and deprecate 'get_transfer'
12:22 kohaputti I think you mean C4::Circulation::GetTransfers ?
12:22 or no?
12:22 ashimema but also update get_transfers to list cancelled_in_transit up high too
12:22 nope..
12:22 right..
12:22 kohaputti ah, there is so many ways to get the transfers
12:23 this one you mean is Koha::Item::get_transfer
12:23 ashimema C4::Circulation::GetTransfers never actually did 's'.. i.e it only ever returns one transfer
12:23 that's what Koha::Item->get_transfer does
12:23 i.e get_transfer was a direct clone of GetTransfers
12:23 I introduced 'get_transfers' later.. and it deals with queues.. so returns an ordered list
12:24 in this case we want that list
12:24 so we can get both transfers.. the one that's 'in_transit and cancelled' and the replacement one too
12:31 davidnind joined #koha
12:34 Dyrcona joined #koha
12:38 kohaputti ashimema, reverse transfer is ?
12:41 https://bugs.koha-community.or[…].cgi?id=27064#c32 victor also seems to have reported a bug
12:41 huginn Bug 27064: normal, P5 - low, ---, nick, Signed Off , Transferring an item with a hold allows the user to set a hold waiting without transferring to the correct branch
12:41 kohaputti "There is a second box"
12:48 ashimema OK.. looking into the second box
12:48 thanks
12:48 reverse transfer..
12:48 the cancellation stuff..
12:49 basically I was trying to fix the orphaned transfers.. so if an item was actually in transit when it's cancelled we added a transfer back to it's originating branch
12:49 that's the 'reverse transfer'
12:50 but in a bunch of cases we don't want it.. hence adding a 'replace' param in the above
12:50 kohaputti ok
12:51 ashimema I have a tweak to get_transfer/get_transfers I'm working on now..
12:51 but I need to work through side effects.. which is going to be fun
12:52 pastebot "ashimema" at 127.0.0.1 pasted "get_transfer query update" (22 lines) at http://paste.koha-community.org/1011
12:52 kohaputti ashimema, it is really bad transferbook does more than just transferring the book... like returns info about holds.
12:52 ashimema yup
12:52 kohaputti really hard to modify this code
12:52 ashimema I'm trying hard to get rid of it
12:53 but I've worked through it at least three times now and found myself tied in knots
12:53 it's a horrible rabbit hole
12:53 at least it's only called in one place now..
12:53 caroline_timelady good <time of day> everyone! How's monday so far?
12:53 ashimema I think allot of the logic should likely go in the controller now instead
12:54 hi caroline_timelady
12:54 kohaputti ashimema, thanks for the info, I will accommodate my critics accordingly then :)
12:55 ashimema hehe
12:55 I am still working towards killing it ;)
12:55 just not in this bug.. ;)
13:01 if it makes you feel any better.. but I think it's unlikely it will.. your 'critical' about the details page not showing the item is in transit.. that actually pre-existed my bug.. you're just drawn to it more now..
13:02 i.e. prior to my bug, the transfer was just completely nuked so you had no idea where the item was at all
13:02 kohaputti oh, I see
13:03 ashimema audit trail in branchtransfers is cool.. but it'shighlighting all sorts of edge cases that were hidden before..
13:03 kohaputti We could lower the priority then
13:03 ashimema I still reckon it's important to fix ;)
13:06 kohaputti ashimema, could we maybe queue those transfers, instead of just cancelling the first one keep it and then make a new one back to the from_library?
13:07 ashimema yeah, in effect that's what I'm thinking..
13:07 kohaputti or maybe you have something already in mind
13:07 ok
13:07 ashimema well.. ish
13:07 right now, if you queue a transfer the first checkin, assuming it's at the right branch, will trigger a 'transfer arrived' dialogue and then you can lend the item etc (to fulfil the hold)..
13:08 it's only on the next checkin you then get notified of the queued transfer
13:08 that works perfectly for successful transfers..
13:08 in this case as we've cancelled the transfer in-transit.. we want to prompt the immediate return on that first checkin..
13:08 I think
13:09 kohaputti ashimema, hmm, are you sure the details page didn't show the item in transit before this bug. I think it might have kept the transfer to the original hold destination and shown it
13:09 I can check but how sure are you? :D
13:09 ashimema I'd just keep the bug at critical and not worry too much about the history ;)
13:10 ModItemTransfer just nuked things..
13:10 but it may have used a different code path to cancel/delete.. one that just set datearrived
13:10 collum joined #koha
13:10 ashimema there's a regression in there somewhere in either case I reckon
13:12 kohaputti hmm, ok. I might check later tonight though so we will keep the functionality similar to how it has been before and don't break any previous workflows due to any new changes we might do
13:12 ashimema good plan
13:12 tcohen morning
13:14 khall joined #koha
13:19 oleonard Hi tcohen
13:32 * ashimema has now removed the superflous error message box on bug 27064
13:32 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=27064 normal, P5 - low, ---, nick, Signed Off , Transferring an item with a hold allows the user to set a hold waiting without transferring to the correct branch
13:32 theodoros joined #koha
13:48 khall_ joined #koha
13:57 kohaputti ashimema, https://bugs.koha-community.or[…]21674&action=diff not sure it is right, shouldn't we just put the line above also in if else so the errmsgloop doesn't get populated
13:57 no need to do anything specific to holds
13:58 ashimema humm
13:58 kohaputti maybe I can send ALT patch :D
13:58 ashimema hehe.. that might help my poor brain ;)
14:05 henryb joined #koha
14:12 kohaputti ashimema, attached it now, can you sign-off if it looks good
14:13 ashimema :)
14:13 kohaputti ashimema, I'm still doing qa on this patch set btw, I think I saw something dodgy earlier
14:13 ashimema :)
14:13 thanks,
14:31 lukeG1 joined #koha
14:38 kohaputti ashimema, how comes bug 27064 is in SO state and I don't see any SO lines?
14:38 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=27064 normal, P5 - low, ---, nick, Signed Off , Transferring an item with a hold allows the user to set a hold waiting without transferring to the correct branch
14:39 kohaputti ah, because it is from Nick originally
14:39 lds_ joined #koha
14:39 fridolin1 left #koha
14:44 kohaputti ashimema, maybe you can think now ;) PQA.
14:45 ashimema aha, I see.. yeah, I like your alt
14:45 nice one
14:49 kohaputti ah, sorry looks like you submitted the patches before and I had those versions with out your SO.. but good you added those back :)
14:49 ashimema haha, no worries
14:49 kohaputti I mean we had a race condition
14:49 ashimema all looks good to me now :)
14:50 I'm attacking your critical now.. have a few various idea's and trying them out now
14:50 kohaputti ashimema, I assume you only added the follow-up earlier? And just submitted again those other bugs with your SO?
14:50 if so, then we are good
14:51 ashimema correct
15:06 kohaputti ashimema, hmm, maybe the logic should be cancel transfer upon arrival?
15:07 ashimema possibly.. but there are lots of ways to cancel a transfer.. not just via holds
15:07 I think
15:08 kohaputti or do we need a new branch location for unknown in-transit location
15:08 then it would be in-transit from unknown location to it's from_library
15:08 ashimema I think I have a fix.. just checking and then will upload
15:08 just so you can see where I'm going..
15:09 kohaputti sounds great
15:09 ashimema I still need to write some unit tests for it to get through QA etc though.
15:12 patch attached
15:13 i went round and round in circles and that the simplest approach in the end..
15:13 basically.. fix the 'in_transit' method back to ignoring cancellation status..
15:14 and update the details controller to use get_transfers (note the 's')..
15:14 the query in that method has been updated to return cancelled but in transit first
15:17 eythian https://www.metafilter.com/191[…]vacy-in-libraries perhaps interesting for people here
15:17 kohaputti ok, trying to understand this now :)
15:19 cait joined #koha
15:20 cait1 joined #koha
15:21 kohaputti ashimema, maybe this could work, then the same fix needs to be put to OPAC too
15:21 and rest?
15:21 where else
15:21 ashimema ah yes.. it does need applying to OPAC too
15:22 I have a bug that starts working through all cases of GetTransfers calls and replaces them with calls to get_transfer
15:22 I think I need to dig that back out and work through each case of that converting to get_transfers and handle it appropriately
15:22 that's bug 24295
15:22 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=24295 enhancement, P5 - low, ---, martin.renvoize, Needs Signoff , C4::Circulation::GetTransfers should be removed, use Koha::Item->get_transfer instead
15:22 kohaputti ashimema, should we remove the from_branch from these cancellation transfers?
15:23 ashimema which I'm about to switch back to 'assigned' now we've uncovered this issue.. I don't think it's ready
15:23 kohaputti ashimema, our librarians got confused because the transfer was from the same branch to same branch
15:23 ashimema I think for audit trail it's helpful to have.. isn't it?
15:23 kohaputti ashimema, like if the from_branch is empty we could show some message that the origin is unknown
15:23 ashimema hum.. but we don't update the 'tobranch'
15:24 kohaputti from_branch
15:24 ashimema so shouldn't it come out as 'from A to B', checkin triggers 'from B to A'
15:24 so I'm not sure where 'from A to A' comes from?
15:24 kohaputti the from_branch is automatically the holdingbranch of item and tobranch is automatically the original transfers from_branch
15:25 ashimema, if the hold is cancelled whilst it still has not been accepted for transfer
15:25 ashimema ah.. for the second transfer..
15:25 yeah..
15:25 I see
15:25 kohaputti I mean someone checks the item in in the from_branch and so the holdingbranch is still that
15:25 I guess it is through the whole transfer actually
15:26 ashimema calling 'transit' should update the 'from_branch' to 'holdingbranch'.. and 'holdingbranch' should have just been updated by the checkin
15:26 I think
15:27 so yeah..
15:27 at 'request time' your right.. from == to..
15:27 but at 'transit time' from will get updated
15:27 I think
15:27 kohaputti wait it is in my example
15:29 ashimema, in the example both frombranch: MPL and tobranch: MPL are same
15:29 https://bugs.koha-community.or[…]_bug.cgi?id=28520
15:29 huginn Bug 28520: critical, P5 - low, ---, koha-bugs, NEW , Cancelling a hold that is in transit hides item's transit status
15:29 ashimema indeed..
15:29 but have you actually set the tranfer to transit ;)
15:30 there's no 'datesent' in the second transfer yet..
15:30 kohaputti let me see, I think I did, by checking in the item
15:30 ashimema ah...
15:30 kohaputti ashimema, the second transfer is the one that was automatically generated by cancelling the hold
15:30 ashimema I bet the 'updatewrongtransfer' stuff isn't kicking in here yet
15:30 indeed
15:30 kohaputti what is updatewrongtransfer stuff? :D
15:31 ashimema bug 24434
15:31 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=24434 major, P5 - low, ---, martin.renvoize, Failed QA , C4::Circulation::updateWrongTransfer is never called but should be
15:31 ashimema basically.. right now if you check an item in at an end location that doesn't match the final tobranch of a transfer.. we don't trigger the onward transfer to the correct location.
15:32 which is a bugger.
15:32 I'm just trying to wrap my head round the QA failure on that one now too
15:32 fun times aye
15:33 kohaputti ashimema, this is hard question. Which branch should the in-transit item be located in
15:34 the destination or from one
15:34 ashimema the current holding.. i.e the 'frombranch'
15:35 kohaputti hmm, let me see what happens when we check-in the item with this cancelled transfer in the original destination branch, whether it updates the frombranch
15:35 ashimema really.. from should only get set at the point of transit and not at the point of request I reckon
15:35 but that idea broke lots of things too early in the refactor
15:35 reiveune bye
15:35 reiveune left #koha
15:36 ashimema good question..
15:36 I get the feeling that without 24434 it won't do anything to the transfer at all..
15:36 I might be wrong..
15:37 kohaputti ashimema, I mean I think in our case if a patron has cancelled the hold it probably is still being transferred to it's original pickup location and then people will check it in there and if it updated the frombranch at that point then when the item returns back home it would have a proper message where it came from
15:37 but if it doesn't update the frombranch to the transfer the message will be weird "transfer to branch A from branch A"
15:38 ashimema when will you see that message?
15:38 remember it's queued..
15:38 hum...
15:38 get_transfer and get_transfers will return a different transfer at the top
15:38 kohaputti not sure, just this is what the librarian reported
15:39 ashimema get_transfer will return the un-cancelled return transfer
15:39 let me run through and test it..
15:39 I've not actually had a moment go test that code I uploaded yet .. haha
15:40 kohaputti ashimema, the code actually doesn't work right because in "+    if ( defined($transfer) && $transfer->in_transit ) {"
15:40 it requires the thing to be in-transit
15:41 but these transfers generated by hold cancellation are not in_transit
15:41 ashimema that's what the change to get_transfers does ;)
15:41 get_transfers returns a list in modified fifo order..
15:41 kohaputti I know, but because of that  && $transfer->in_transit part it doesn't get displayed
15:41 ashimema it'll return 'in_transit' first always (including cancelled whilst in transit)
15:42 I also modified 'in_transit' in that patch ;)
15:42 to ignore cancelleddate
15:42 so in_transit should be true
15:42 kohaputti datesent is null
15:42 ashimema wha...
15:42 using your example
15:43 kohaputti the hold has been just cancelled, nobody has yet checked the item in, it is still in the transportation van
15:43 ashimema get_transfers should return transfer 1 at the top
15:43 which has a transfer
15:43 kohaputti so the datesent is null
15:44 ooh... hmm
15:44 does it show the old transfer?
15:44 wait..
15:44 maybe it does
15:44 sorry
15:44 ashimema yes
15:44 :)
15:44 kohaputti so confusing :D
15:44 ashimema yeah..
15:45 I'm not sure about it..
15:45 though I think the logic is mostly sound now.. it feels a bit dirty and confusing
15:46 aha..
15:46 I think I have a nicer solution.. that ditches the immediate creation of the return transfer again
15:46 that's cleaner
15:46 kohaputti when will it do it?
15:46 ashimema at the checkin
15:46 like you suggested
15:47 kohaputti ok! I actually worked on another bug relating to this and wanted to do it on check-in back then as well
15:47 ashimema the core thing is.. we need to check get_transfers instead of get_transfer
15:47 haha
15:47 cool
15:47 I just couldn't work out how to before..
15:47 light bulb moment
15:48 kohaputti I didn't work on it more because I thought bug 12362 solved it
15:48 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=12362 normal, P5 - low, ---, martin.renvoize, Pushed to master , Branch transfer records orphaned on cancelled holds
15:48 kohaputti hopefully this check-in idea will work
15:49 ashimema I think Petro confused me a while back.. I can't have understood something he said
15:49 it's all coming back now :)
15:50 kohaputti ashimema, maybe it is actually best we require the transfer to go to it's destination and then come back, because you know, you don't have to do that physically, the librarian can just juggle the branches in intranet to fake the book has traveled the world :)
15:50 and, that was the old behaviour before bug 12362
15:50 ashimema agreed
15:50 Dyrcona eythian: I found that metafilter link and the surrounding discussion to be of interest. Personally Identifiable information was covered in the keynote and a lightning talk at this year's Evergreen conference.
15:50 kohaputti though before the triggering to back home didn't work well
15:51 you had to check-in twice at the cancelled hold's pickup branch to make it go back home
15:52 davidnind joined #koha
15:57 kohaputti ashimema, I'm actually bit unsure what is your idea and how it would work. My current idea would be to keep the transfer and not cancel it and on destination check-in check whether there is still an T type reserve for the item if the transfer reason = "Reserve"
15:58 and if there is no reserve then create a new transfer back home
15:58 ashimema My idea is to 'cancel' the transfer by setting the cancellation_reason and date.. but not create drop the creation of the return transfer at that point..
15:59 kohaputti but then we have no transfer?
15:59 ashimema instead.. call get_transfers (with the updated logic that returns 'in_transit' at the top, regardless of whether it was cancelled or not
15:59 kohaputti ah, ok
15:59 ashimema then check for cancellation_reason (or cancellationdate)
15:59 and if found, add the return transfer at that point
15:59 or rather.. ask the librarian if they want to add it.
16:00 kohaputti hmm.. and ok, then the in_transit check would be back to the previous
16:00 return ( defined( $self->datesent )
16:00 && !defined( $self->datearrived )
16:00 ashimema that way we catch your case for hold cancellations.. but also catch other cancellation reasons.
16:00 exactly
16:00 kohaputti we would drop the           && !defined( $self->datecancelled ) );
16:00 from in_transit
16:00 ashimema I think that's the addition that really screwed the pooch as it were
16:00 that was added at Patro's request.. well.. I thought it made sense and it flew through QA :P
16:01 clearly I didn't fully anticipate the circular dependancy it left us iwth
16:07 khall joined #koha
16:09 kohaputti ashimema, hmm, I think I found the culprit for the original problem actually. Do you see how the $validTransfer variable is set in the Circulation.pm code, it disabled the return to home branch on check-in
16:09 let me see if git blame tells us more
16:12 Bug 26078: (follow-up) Use a boolean rather than changing returnbranch
16:12 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=26078 major, P5 - low, ---, nick, Pushed to oldstable , "Item returns to issuing library" creates infinite transfer loop
16:12 kohaputti this seems to have changed the behaviour
16:12 it also added the comment:
16:12 +        # At this point we will either fill the transfer or it is a wrong transfer
16:12 +        # either way we should not now generate a new transfer
16:13 but seems like it broke this workflow
16:22 ashimema, maybe just set $validTransfer = 1 if we come across canceled transfer which is not yet arrived?
16:22 and also revert the is_transit logic
16:23 ashimema something along those lines
16:23 gotta cook tea and take kids to clubs
16:23 will continue on this, this evening
16:23 kohaputti ok, I will also go now, see you tomorrow
16:25 ashimema Have a good evening
16:34 collum joined #koha
16:49 khall_ joined #koha
16:51 nugged > gotta cook tea and take kids to clubs
16:51 ashimema: 🤗
16:57 oleonard ashimema++
16:57 collum joined #koha
16:57 oleonard kohaputti++
17:14 kohaputti ashimema, I just pushed some patches and it fixes the triggering of transfer back home, the patches depend on the bug 27064 we just worked earlier today on.
17:14 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=27064 normal, P5 - low, ---, nick, Passed QA , Transferring an item with a hold allows the user to set a hold waiting without transferring to the correct branch
17:14 kohaputti ashimema, however, I don't know how the stockrotation feature works with this...
17:16 ashimema are those patches you pushed public somewhere?
17:18 kohaputti bug 28520
17:18 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=28520 critical, P5 - low, ---, koha-bugs, NEW , Cancelling a hold that is in transit hides item's transit status
17:18 ashimema yup.. found them
17:18 kohaputti I think it requires probably the adaptation to the stockrotation thing but maybe you could have a look?
17:18 reiveune joined #koha
17:18 ashimema I find the 'validTransfer' stuff confusing.. it's been a while since I wrapped my head around that
17:19 I like your patches though.. they progress where I was going nicely
17:19 kohaputti ashimema, can you tell me why stockrotation cancels transfers?
17:20 where are the items supposed to be after they are cancelled, like can we just finish the transfer instead?
17:21 ashimema erm
17:21 kohaputti oh, we need a patch to rename that "replace" parameter btw, it is not very descriptive
17:21 ashimema I don't see where stockrotation cancels transfers..
17:21 yeah.
17:21 kohaputti let me find it, I think it did that
17:21 ashimema ack.. i have kids screaming at me now
17:22 or do you mean rotating collections
17:22 they're pretty different features
17:22 reiveune left #koha
17:23 kohaputti ashimema, It is this rotating colleciton
17:23 ah ok, I thought they were the same
17:23 both have collection in the name :DD
17:24 in RotatingCollections.pm there is:
17:24 my $transfer = $item_object->request_transfer(
17:24 which passes replace => 1 which means we try cancel the transfer
17:29 There is also one call with replace => 1 in StockRotationItem.pm and ModItemTransfer.pm
17:29 so total we have 3 places we need to check whether it is okay or need to be re-written some other way
17:31 aha, in ModItemTransfer we can revert to the previous behaviour, which is to set the transfer arrived
17:32 (that was done in bug Bug 24446)
17:32 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=24446 enhancement, P5 - low, ---, martin.renvoize, Pushed to master , Stockrotation: Update to use daterequested in branchtransfers
17:38 ashimema ok
17:38 will take another look this evening
17:59 collum joined #koha
18:08 kohaputti ashimema, we could also just revert the "Bug 12362: Cancel transfer with hold cancelation" where the transfer is cancelled, to restore the previous behaviour which a lot better than having incorrect availability info
18:08 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=12362 normal, P5 - low, ---, martin.renvoize, Pushed to master , Branch transfer records orphaned on cancelled holds
18:11 kohaputti let me do that actually and send patches..
18:11 I can also do the fix by checking if there is any hold to full-fill
18:12 trying to change the meaning of that cancellationdate is a slippery slope and could probably cause more regressions
18:12 so it needs to be done with a good amount of time and in small pieces
18:14 paxed /win 14
18:14 oops
18:18 cait joined #koha
18:19 cait1 joined #koha
18:24 marie-luce joined #koha
18:28 davidnind left #koha
19:01 kohaputti ashimema, found the perfect patch, attached it in the report :)
19:04 cait1 "the perfect patch"
19:05 :)
19:05 kohaputti++ ashimema++
19:05 bye :)
19:05 cait1 left #koha
19:05 cait joined #koha
19:19 lukeG joined #koha
23:23 dcook Thanks, Joubu. I've been wanting to do bug 28519 for years, so I'm glad I finally had the motivation.
23:23 huginn Bug https://bugs.koha-community.or[…]_bug.cgi?id=28519 enhancement, P5 - low, ---, dcook, Needs Signoff , Add a 2nd directory for Perl modules

← Previous day | Today | Next day → | Search | Index

koha1