Time Nick Message 23:32 aleisha yeah normally in the months leading up to the academy we do a big push for academy bugs 23:18 tuxayo Maybe before the academy we could find need SO bugs that have been flagged? 23:17 tuxayo Most are new or are in the various ~blocked states due to issues. 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 caroline_timelady: hi :) 22:05 aleisha oops sorry yes same! 21:31 caroline_timelady how about you? 21:31 caroline_timelady keeping busy for sure! 21:31 aleisha how are you going caroline_timelady ? 21:15 caroline_timelady good morning aleisha! 21:14 aleisha good morning from nz! 20:58 caroline_timelady can that be right? 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 I only found 3 Academy in Need Signoff 20:58 caroline_timelady I need easy bugs to sign off for a new intern 18:16 oleonard I had to give a cleansing growl to clarify my mind 18:15 tuxayo grumpy oleonard-away 18:07 oleonard-away GRR 15:39 reiveune bye 13:25 oleonard Oh wow the OverDrive account information in the OPAC needs work... 13:19 oleonard Oh wait, it's actually looking for OverDriveWebsiteID isn't it... 13:19 oleonard I'm getting the message 'OverDrive Library ID not provided' but I do have OverDriveLibraryID populated 13:18 oleonard Anyone around who has experience troubleshooting OverDrive login in the OPAC? 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 12:48 tcohen @seen Joubu 12:25 mtj Joubu: re 17427, i cant see a problem making a Data::Session pkg 12:17 mtj hi tcohen, about now 11:56 ashimema I've told her a few time tcohen ;) 11:21 cait1 tcohen: nah 11:21 huginn tcohen: The operation succeeded. 11:21 tcohen @later tell cait you need a bouncer 10:57 cait brb as cait1 or so 10:57 cait German speaking Koha users meeting 10:56 cait now i got to finish my slides for tomorrow :) 10:55 cait fridolin: just did - thx :) 10:55 fridolin cait yep dont hesitate to mail 10:54 cait including it as an example 10:54 cait thx 10:53 oleonard I did not get it 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:48 tcohen :-D 10:47 cait oleonard: i am sending an email to lds cc Joubu 10:47 cait morning tcohen 10:47 tcohen morning 10:41 cait no koha-devel ones for example 10:40 cait i think there is an issue with the latter 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:39 cait hm or maybe not, I only see koha . this is the katipo server 10:39 oleonard Yes I have email from the koha list this morning 10:39 cait koha-bugs especially it looks like - other seem to go through? 10:38 cait fridolin: any chance youc ould ask lds of there is something going on with the mailserver? 10:38 cait so it will make no sense to email my provider 10:38 cait oh you too then 10:37 oleonard cait: I knew there was a reason my email looked empty... no Bugzilla mails! 09:50 fribeiro All of those seems to be ok. Btw, I'm in Koha 16.11 09:48 kohaputti so many settings :D 09:48 kohaputti fribeiro, there is also RestrictionBlockRenewing :D 09:47 fribeiro I will check those settings 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:44 kohaputti or maybe AllFinesNeedOverride 09:44 kohaputti if you search with "override" in sysprefs there is quite many settings you can tweak 09:43 kohaputti or maybe AllowRenewalLimitOverride also 09:43 kohaputti fribeiro, maybe AllowFineOverride needs to be changed if you want it to behave different 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:31 cait1 if anyone is aware of any changes, Joubu maybe? 09:31 cait1 it stopped sometime yesterday 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:29 cait1 I am no longer receiving bugzilla list emails to my qam inbox :( 08:41 ashimema K, will take a look after my call 08:41 kohaputti ashimema, the patches are now ready to review 07:43 kohaputti ok, yeah, I think it is possible to fix it later because we can do for example that aforementioned db upgrade 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:42 ashimema I'll fix all that on another bug.. go ahead with your minimal approach here kohaputti 07:42 kohaputti or if we take, then probably the datereceived needs to be populated with the cancelleddate 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:39 * ashimema needs more coffee.. already struggling to juggle everything today :( 07:36 ashimema that is the bug in my opinion 07:36 ashimema the intention was lost when the in_transit code had 'datecancelled => undef' added.. 07:35 ashimema not with the first patch on 25820.. 07:35 kohaputti so in our current code that line of code marks the transfer to be totally finished 07:35 kohaputti currently in our code being in transit is something that doesn't have cancelleddate or datearrive and has datesent 07:34 ashimema so if it's in transit.. it's still in transit 07:33 ashimema it doesn't set the datearrived 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 sets the cancellation_date.. 07:32 kohaputti which cancels the transfer without finishing it 07:32 kohaputti with replace = 1 07:32 kohaputti my $transfer = $item_object->request_transfer( 07:31 kohaputti C4/RotatingCollections.pm there is a call 07:29 ashimema I don't see where in rotating collections your looking 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: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:27 ashimema just drop the creation of the reverse transfer 07:27 ashimema I still feel like we should leave the cancellation call in Koha::Hold personally. 07:26 ashimema it'll likely never go away... 07:26 kohaputti I mean just the DB enum 07:25 kohaputti ashimema, hmm, maybe keep the TransferCancellation around for few releases? 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:20 kohaputti bug 28382 07:19 ashimema and 28382 for that matter 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 personally.. I see bug 24434 as a much bigger deal 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:17 ashimema so delete those transfer lines as a db update 07:16 kohaputti yes, the ones using 21.05 07:16 ashimema it only came in in 21.05 07:16 ashimema how 07:16 kohaputti well, people are already using it :P 07:16 ashimema because it will never be used 07:16 kohaputti why? 07:16 ashimema including the db update 07:16 kohaputti well, except the db part 07:15 ashimema revert 12362 in it's entirety then 07:14 ashimema ok 07:12 kohaputti I'd like us to fix fix the regression and think new features later, like that better tracking 07:12 ashimema I suppose it doesn't really matter 07:11 ashimema but I'm also thinking for audit 07:11 ashimema we could in this case 07:11 ashimema true 07:10 kohaputti we know we had a transfer for a 'Reserve' and if there is no reserve then display that error 07:10 ashimema yes.. exactly 07:10 ashimema so we use the 'reason' + 'cancellation_reason' to build that message 07:10 kohaputti well, we could add the message via the AddReturn code 07:09 ashimema that's the 'transfer cancelled' 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 kohaputti but what's the problem letting the transfer finish because it will come back home when checked-in the next time? 07:08 ashimema it just happens to already by in the van on the way there 07:08 ashimema but it's not.. we don't want it at the pickup location 07:08 kohaputti we clearly are not cancelling it if it is still intended to go to the holds pickup location 07:07 kohaputti But... why cancel the transfer, because I don't see how we are cancelling it 07:07 ashimema with the first patch on 28520 it does 07:06 kohaputti cancelled transfer* 07:06 kohaputti cancelled hold means a non-active hold, and it doesn't show anywhere 07:06 ashimema it would be.. it's still there.. just marked as cancelled 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 kohaputti ashimema, also you commented like that :D 07:05 kohaputti I would expect it to stay in effect also 07:05 kohaputti from Owen 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 wasn't in the* 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:04 ashimema hte hold has been cancelled.. as such the transfer it created should too.. 07:03 ashimema like the bug says. 07:03 ashimema because otherwise it's left orphaned 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 kohaputti why would we want to cancel it? 07:02 ashimema the `if ($self->is_in_transit)` block 07:02 ashimema I think we still want the bit in Koha::Hold 07:01 ashimema almost 07:01 kohaputti I'd like to get rid of the reverse transfer too because it made the code look complicated 07:00 kohaputti i.e. the 3 last patches 07:00 kohaputti so we revert bug 12362 totally except for the database update? 07:00 ashimema adding that reverse transfer in at all was a mistake 07:00 ashimema all related to the same thing really 07:00 ashimema for another bugfix 06:59 ashimema in my tree, we also add the replace call into that cancel ;) 06:59 dcook Anyway I better run 06:59 dcook cait1: I thought that you were saying you ran into the issue on 2021-06-03? 06:58 kohaputti so I think we cannot just revert it now, or can we? 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 ashimema, I think there was the commit "Bug 12362: (QA follow-up) Fix ModItemTransfer cancellation handling" which calls it then 06:58 ashimema though.. I still think we aught to cancel the transfer.. just not add the reversal 06:57 magnuse \o/ 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:56 cait1 but there are other sources 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 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: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:55 cait1 look at the dates :) 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: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:49 dcook I was able to get yaz-client and ZOOM working with a Squid HTTP forward proxy.. 06:49 dcook But if you are having an issue there, I'd be keen to hear your thoughts 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 cait1: It looks like Dan has disappeared from bug 12620 06:49 * dcook waves 06:46 alex_a Bonjour 06:42 cait1 good morning #koha 06:38 reiveune hello 06:25 fridolin hi 06:18 huginn dcook: The operation succeeded. 06:18 dcook @later tell cait1 let me know what you think about bug 12620 03:07 aleisha Joubu khall_ tuxayo ^ 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:04 aleisha hello