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