Time Nick Message 03:04 aleisha hello 03:05 aleisha Wainui is ready to take on release maintenance now! but it seems the wiki might be a bit out of date and we're waiting on a handover :) https://wiki.koha-community.org/wiki/Release_maintenance 03:07 aleisha Joubu khall_ tuxayo ^ 06:18 dcook @later tell cait1 let me know what you think about bug 12620 06:18 huginn dcook: The operation succeeded. 06:25 fridolin hi 06:38 reiveune hello 06:42 cait1 good morning #koha 06:46 alex_a Bonjour 06:49 * dcook waves 06:49 dcook cait1: It looks like Dan has disappeared from bug 12620 06:49 huginn Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12620 enhancement, P5 - low, ---, koha-bugs, NEW , Proxy Add-on for Koha z39.50/SRU servers 06:49 dcook But if you are having an issue there, I'd be keen to hear your thoughts 06:49 dcook I was able to get yaz-client and ZOOM working with a Squid HTTP forward proxy.. 06:50 dcook Mostly just because I love networking stuff. I don't think any of my clients have a use for it at this time. 06:55 cait1 dcook: yep, it was an old bug, i just had the issue with another student project - that's why I commented 06:55 cait1 look at the dates :) 06:55 kohaputti ashimema, does the hold transfer fix idea look okay in general to you? If so I will work on the unit tests and better commit message 06:56 cait1 dcook: thx for looking into it... i sent the bug to the admin their, but at the momen tI thinkw e won't be able to use SRU targets there, which is a pity because german national library only offers SRU 06:56 ashimema kohaputti.. as we've gone through the codebase now and pretty much added the 'replace' call to all calls to request_transfer.. I think we should probably just outright drop the reverse transfer logic that adds those in the first place.. as we're not never calling it ;) 06:56 cait1 but there are other sources 06:56 ashimema yes.. I think it looks good.. it's a lighter touch than what I was doing bug achieves the exact same thing.. 06:57 magnuse \o/ 06:58 ashimema though.. I still think we aught to cancel the transfer.. just not add the reversal 06:58 kohaputti ashimema, I think there was the commit "Bug 12362: (QA follow-up) Fix ModItemTransfer cancellation handling" which calls it then 06:58 huginn Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12362 normal, P5 - low, ---, martin.renvoize, Pushed to master , Branch transfer records orphaned on cancelled holds 06:58 kohaputti so I think we cannot just revert it now, or can we? 06:59 dcook cait1: I thought that you were saying you ran into the issue on 2021-06-03? 06:59 dcook Anyway I better run 06:59 ashimema in my tree, we also add the replace call into that cancel ;) 07:00 ashimema for another bugfix 07:00 ashimema all related to the same thing really 07:00 ashimema adding that reverse transfer in at all was a mistake 07:00 kohaputti so we revert bug 12362 totally except for the database update? 07:00 kohaputti i.e. the 3 last patches 07:01 kohaputti I'd like to get rid of the reverse transfer too because it made the code look complicated 07:01 ashimema almost 07:02 ashimema I think we still want the bit in Koha::Hold 07:02 ashimema the `if ($self->is_in_transit)` block 07:03 kohaputti why would we want to cancel it? 07:03 ashimema so that we can cancel the transfer.. then the first patch I add here makes sure we don't exclude cancelled in transit transfers 07:03 ashimema because otherwise it's left orphaned 07:03 ashimema like the bug says. 07:04 ashimema hte hold has been cancelled.. as such the transfer it created should too.. 07:04 kohaputti why should the transfer be cancelled? Wasn't the original bug report a statement also from others we should not touch the transfer but leave it and wait for it to finish 07:05 kohaputti wasn't in the* 07:05 kohaputti "If a transfer has been initiated because of a hold I would expect the transfer to remain in effect until completed by a check-in:" 07:05 kohaputti from Owen 07:05 kohaputti I would expect it to stay in effect also 07:06 kohaputti ashimema, also you commented like that :D 07:06 kohaputti "I agree with Owen.. simply cancelling the hold shouldn't mark an in-progress transfer as completed.. we need to perform a check-in to know where the item actually is." 07:06 ashimema it would be.. it's still there.. just marked as cancelled 07:06 kohaputti cancelled hold means a non-active hold, and it doesn't show anywhere 07:06 kohaputti cancelled transfer* 07:07 ashimema with the first patch on 28520 it does 07:07 kohaputti But... why cancel the transfer, because I don't see how we are cancelling it 07:08 kohaputti we clearly are not cancelling it if it is still intended to go to the holds pickup location 07:08 ashimema but it's not.. we don't want it at the pickup location 07:08 ashimema it just happens to already by in the van on the way there 07:09 kohaputti but what's the problem letting the transfer finish because it will come back home when checked-in the next time? 07:09 ashimema van arrives at library b, librarian checks items in and is immediately prompted to put it back on the van without a reason.. it's the 'without a reason' that grates on me.. at that point we should be able to say 'The hold was cancelled, so send it back' 07:09 ashimema that's the 'transfer cancelled' 07:10 kohaputti well, we could add the message via the AddReturn code 07:10 ashimema so we use the 'reason' + 'cancellation_reason' to build that message 07:10 ashimema yes.. exactly 07:10 kohaputti we know we had a transfer for a 'Reserve' and if there is no reserve then display that error 07:11 ashimema true 07:11 ashimema we could in this case 07:11 ashimema but I'm also thinking for audit 07:12 ashimema I suppose it doesn't really matter 07:12 kohaputti I'd like us to fix fix the regression and think new features later, like that better tracking 07:14 ashimema ok 07:15 ashimema revert 12362 in it's entirety then 07:16 kohaputti well, except the db part 07:16 ashimema including the db update 07:16 kohaputti why? 07:16 ashimema because it will never be used 07:16 kohaputti well, people are already using it :P 07:16 ashimema how 07:16 ashimema it only came in in 21.05 07:16 kohaputti yes, the ones using 21.05 07:17 ashimema so delete those transfer lines as a db update 07:18 kohaputti I'm not sure it is a good idea to delete, we are then left without any active transfer/transfer request 07:19 ashimema personally.. I see bug 24434 as a much bigger deal 07:19 huginn Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24434 major, P5 - low, ---, martin.renvoize, Failed QA , C4::Circulation::updateWrongTransfer is never called but should be 07:19 ashimema and 28382 for that matter 07:20 kohaputti bug 28382 07:20 huginn Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28382 enhancement, P5 - low, ---, martin.renvoize, Signed Off , 'Reserve' should be passed through as transfer reason appropriately in branchtransfers 07:25 kohaputti ashimema, hmm, maybe keep the TransferCancellation around for few releases? 07:26 kohaputti I mean just the DB enum 07:26 ashimema it'll likely never go away... 07:27 ashimema I still feel like we should leave the cancellation call in Koha::Hold personally. 07:27 ashimema just drop the creation of the reverse transfer 07:28 kohaputti ashimema, but then it is weird that we have those rotating collection transfer using cancellation to mean they are not in transit anymore, right? Wouldn't there be double meaning to cancellation then 07:29 kohaputti but if for hold transfer it means that it is still in-transit but we just don't want it, it is very confusing then 07:29 ashimema I don't see where in rotating collections your looking 07:31 kohaputti C4/RotatingCollections.pm there is a call 07:32 kohaputti my $transfer = $item_object->request_transfer( 07:32 kohaputti with replace = 1 07:32 kohaputti which cancels the transfer without finishing it 07:33 ashimema it sets the cancellation_date.. 07:33 kohaputti also I think we had the lost item code which uses the cancellationdate to mark that it is fully cancelled and not in-transit 07:33 ashimema it doesn't set the datearrived 07:34 ashimema so if it's in transit.. it's still in transit 07:35 kohaputti currently in our code being in transit is something that doesn't have cancelleddate or datearrive and has datesent 07:35 kohaputti so in our current code that line of code marks the transfer to be totally finished 07:35 ashimema not with the first patch on 25820.. 07:36 ashimema the intention was lost when the in_transit code had 'datecancelled => undef' added.. 07:36 ashimema that is the bug in my opinion 07:39 * ashimema needs more coffee.. already struggling to juggle everything today :( 07:41 kohaputti ashimema, hmm, it is not gonna be easy to take the first patch from 25820 anymore in since we have those transfers already created that are cancelled and really finished, so after the upgrade those would pop-up again 07:42 kohaputti or if we take, then probably the datereceived needs to be populated with the cancelleddate 07:42 ashimema I'll fix all that on another bug.. go ahead with your minimal approach here kohaputti 07:43 ashimema I really need to move on to other things.. I have a weeks catchup of customer calls and things to do 07:43 kohaputti ok, yeah, I think it is possible to fix it later because we can do for example that aforementioned db upgrade 08:41 kohaputti ashimema, the patches are now ready to review 08:41 ashimema K, will take a look after my call 09:29 cait1 I am no longer receiving bugzilla list emails to my qam inbox :( 09:29 cait1 just to let you know... as my workflow is based mostly on it, I need to figure out something but might not be responsive until then 09:31 cait1 it stopped sometime yesterday 09:31 cait1 if anyone is aware of any changes, Joubu maybe? 09:38 fribeiro Hello guys. Is it normal to a librarian be able to renew a loan for a borrowers with fines? That borrower can not renew on his OPAC page. However, a librarian can renew it ignoring all fines 09:43 kohaputti fribeiro, maybe AllowFineOverride needs to be changed if you want it to behave different 09:43 kohaputti or maybe AllowRenewalLimitOverride also 09:44 kohaputti if you search with "override" in sysprefs there is quite many settings you can tweak 09:44 kohaputti or maybe AllFinesNeedOverride 09:46 fribeiro thank you for your help. In fact, the librarian can not create a loan if a fine was not paid. However, if a loan was made before the fine, it can be renewed 09:47 fribeiro I will check those settings 09:48 kohaputti fribeiro, there is also RestrictionBlockRenewing :D 09:48 kohaputti so many settings :D 09:50 fribeiro All of those seems to be ok. Btw, I'm in Koha 16.11 10:37 oleonard cait: I knew there was a reason my email looked empty... no Bugzilla mails! 10:38 cait oh you too then 10:38 cait so it will make no sense to email my provider 10:38 cait fridolin: any chance youc ould ask lds of there is something going on with the mailserver? 10:39 cait koha-bugs especially it looks like - other seem to go through? 10:39 oleonard Yes I have email from the koha list this morning 10:39 cait hm or maybe not, I only see koha . this is the katipo server 10:40 cait koha main mailing list is a different mail server, the topic ones like koha-devel and koha-bugs are all on biblibre's server 10:40 cait i think there is an issue with the latter 10:41 cait no koha-devel ones for example 10:47 tcohen morning 10:47 cait morning tcohen 10:47 cait oleonard: i am sending an email to lds cc Joubu 10:48 tcohen :-D 10:53 cait oleonard: can you confirm you didn't get ths one here? https://lists.koha-community.org/pipermail/koha-devel/2021-June/046534.html 10:53 oleonard I did not get it 10:54 cait thx 10:54 cait including it as an example 10:55 fridolin cait yep dont hesitate to mail 10:55 cait fridolin: just did - thx :) 10:56 cait now i got to finish my slides for tomorrow :) 10:57 cait German speaking Koha users meeting 10:57 cait brb as cait1 or so 11:21 tcohen @later tell cait you need a bouncer 11:21 huginn tcohen: The operation succeeded. 11:21 cait1 tcohen: nah 11:56 ashimema I've told her a few time tcohen ;) 12:17 mtj hi tcohen, about now 12:25 mtj Joubu: re 17427, i cant see a problem making a Data::Session pkg 12:48 tcohen @seen Joubu 12:48 huginn tcohen: Joubu was last seen in #koha 1 day, 5 hours, 25 minutes, and 55 seconds ago: <Joubu> thx dcook for bug 28519 13:18 oleonard Anyone around who has experience troubleshooting OverDrive login in the OPAC? 13:19 oleonard I'm getting the message 'OverDrive Library ID not provided' but I do have OverDriveLibraryID populated 13:19 oleonard Oh wait, it's actually looking for OverDriveWebsiteID isn't it... 13:25 oleonard Oh wow the OverDrive account information in the OPAC needs work... 15:39 reiveune bye 18:07 oleonard-away GRR 18:15 tuxayo grumpy oleonard-away 18:16 oleonard I had to give a cleansing growl to clarify my mind 20:58 caroline_timelady I need easy bugs to sign off for a new intern 20:58 caroline_timelady I only found 3 Academy in Need Signoff 20:58 caroline_timelady https://bugs.koha-community.org/bugzilla3/buglist.cgi?bug_status=Needs%20Signoff&keywords=Academy%2C%20&keywords_type=allwords&list_id=374709&query_format=advanced 20:58 caroline_timelady can that be right? 21:14 aleisha good morning from nz! 21:15 caroline_timelady good morning aleisha! 21:31 aleisha how are you going caroline_timelady ? 21:31 caroline_timelady keeping busy for sure! 21:31 caroline_timelady how about you? 22:05 aleisha oops sorry yes same! 23:17 tuxayo caroline_timelady: hi :) 23:17 tuxayo That seems about right. Academy bug tend to get signed off with priority during the Academy to make them go into master, not staying in that state for too long. 23:17 tuxayo Most are new or are in the various ~blocked states due to issues. 23:18 tuxayo Maybe before the academy we could find need SO bugs that have been flagged? 23:32 aleisha yeah normally in the months leading up to the academy we do a big push for academy bugs