← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
00:46 | Wainui joined #koha | |
03:04 | aleisha joined #koha | |
03:04 | aleisha | hello |
03:04 | Wainui joined #koha | |
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.or[…]lease_maintenance |
03:07 | Joubu khall_ tuxayo ^ | |
03:08 | Wainui joined #koha | |
03:09 | Wainui joined #koha | |
05:22 | JBoyer joined #koha | |
06:18 | dcook | @later tell cait1 let me know what you think about bug 12620 |
06:18 | huginn | dcook: The operation succeeded. |
06:24 | fridolin joined #koha | |
06:25 | fridolin | hi |
06:33 | cait joined #koha | |
06:35 | cait1 joined #koha | |
06:37 | reiveune joined #koha | |
06:38 | reiveune | hello |
06:40 | sophie_m joined #koha | |
06:42 | cait1 | good morning #koha |
06:46 | alex_a joined #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.or[…]_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 | I was able to get yaz-client and ZOOM working with a Squid HTTP forward proxy.. | |
06:50 | 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 | 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.or[…]_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 | Anyway I better run | |
06:59 | ashimema | in my tree, we also add the replace call into that cancel ;) |
07:00 | for another bugfix | |
07:00 | all related to the same thing really | |
07:00 | 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 | lds joined #koha | |
07:00 | kohaputti | i.e. the 3 last patches |
07:01 | I'd like to get rid of the reverse transfer too because it made the code look complicated | |
07:01 | ashimema | almost |
07:02 | I think we still want the bit in Koha::Hold | |
07:02 | 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 | because otherwise it's left orphaned | |
07:03 | like the bug says. | |
07:04 | 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:04 | alex_a joined #koha | |
07:05 | kohaputti | wasn't in the* |
07:05 | "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 | from Owen | |
07:05 | I would expect it to stay in effect also | |
07:06 | ashimema, also you commented like that :D | |
07:06 | "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 | 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 | 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 | 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 | 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 | 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 | we could in this case | |
07:11 | but I'm also thinking for audit | |
07:12 | paul_p joined #koha | |
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 | 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 | 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.or[…]_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.or[…]_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 | I mean just the DB enum | |
07:26 | ashimema | it'll likely never go away... |
07:27 | I still feel like we should leave the cancellation call in Koha::Hold personally. | |
07:27 | 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 | 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 | my $transfer = $item_object->request_transfer( | |
07:32 | with replace = 1 | |
07:32 | 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 | 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 | 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 | the intention was lost when the in_transit code had 'datecancelled => undef' added.. | |
07:36 | 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 | 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 | 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 |
07:57 | MarkHofstetter joined #koha | |
08:10 | lds_ joined #koha | |
08:41 | kohaputti | ashimema, the patches are now ready to review |
08:41 | ashimema | K, will take a look after my call |
08:57 | theodoros left #koha | |
08:57 | theodoros joined #koha | |
09:04 | fridolin joined #koha | |
09:13 | fribeiro joined #koha | |
09:29 | cait1 | I am no longer receiving bugzilla list emails to my qam inbox :( |
09:29 | 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 | it stopped sometime yesterday | |
09:31 | if anyone is aware of any changes, Joubu maybe? | |
09:36 | fribeiro joined #koha | |
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 | or maybe AllowRenewalLimitOverride also | |
09:44 | if you search with "override" in sysprefs there is quite many settings you can tweak | |
09:44 | 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 | I will check those settings | |
09:48 | kohaputti | fribeiro, there is also RestrictionBlockRenewing :D |
09:48 | so many settings :D | |
09:50 | fribeiro | All of those seems to be ok. Btw, I'm in Koha 16.11 |
10:14 | cait joined #koha | |
10:34 | alex_a joined #koha | |
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 | so it will make no sense to email my provider | |
10:38 | fridolin: any chance youc ould ask lds of there is something going on with the mailserver? | |
10:39 | 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 | 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 | i think there is an issue with the latter | |
10:41 | no koha-devel ones for example | |
10:47 | tcohen | morning |
10:47 | cait | morning tcohen |
10:47 | 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.o[…]-June/046534.html |
10:53 | oleonard | I did not get it |
10:54 | cait | thx |
10:54 | including it as an example | |
10:55 | fridolin | cait yep dont hesitate to mail |
10:55 | cait | fridolin: just did - thx :) |
10:56 | now i got to finish my slides for tomorrow :) | |
10:56 | fridolin left #koha | |
10:57 | cait | German speaking Koha users meeting |
10:57 | 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:40 | khall joined #koha | |
11:51 | MarkHofstetter joined #koha | |
11:51 | collum joined #koha | |
11:56 | ashimema | I've told her a few time tcohen ;) |
12:17 | mtj | hi tcohen, about now |
12:25 | Joubu: re 17427, i cant see a problem making a Data::Session pkg | |
12:43 | Dyrcona joined #koha | |
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 |
12:55 | marie-luce joined #koha | |
13:18 | oleonard | Anyone around who has experience troubleshooting OverDrive login in the OPAC? |
13:19 | I'm getting the message 'OverDrive Library ID not provided' but I do have OverDriveLibraryID populated | |
13:19 | Oh wait, it's actually looking for OverDriveWebsiteID isn't it... | |
13:24 | Oh wow the OverDrive account information in the OPAC needs work... | |
14:44 | khall_ joined #koha | |
15:14 | cait1 left #koha | |
15:15 | cait joined #koha | |
15:16 | cait joined #koha | |
15:18 | fridolin joined #koha | |
15:39 | reiveune | bye |
15:40 | reiveune left #koha | |
15:44 | khall joined #koha | |
16:49 | cait joined #koha | |
17:12 | collum joined #koha | |
17:13 | reiveune joined #koha | |
17:13 | reiveune left #koha | |
17:57 | fridolin left #koha | |
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:24 | lisettelatah joined #koha | |
20:37 | z-b joined #koha | |
20:58 | caroline_timelady | I need easy bugs to sign off for a new intern |
20:58 | I only found 3 Academy in Need Signoff | |
20:58 | https://bugs.koha-community.or[…]y_format=advanced | |
20:58 | 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 | how about you? | |
22:05 | aleisha | oops sorry yes same! |
23:17 | tuxayo | caroline_timelady: hi :) |
23:17 | 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 | Most are new or are in the various ~blocked states due to issues. | |
23:18 | 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 |
← Previous day | Today | Next day → | Search | Index