← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 03:38 | Oak joined #koha | |
| 05:44 | fridolin joined #koha | |
| 06:22 | thibaud_g joined #koha | |
| 06:33 | kim joined #koha | |
| 06:35 | kim | Hi, just wanna ask if do we need to pay anything if we wanted to change our library system into Koha? |
| 07:04 | davidnind | kim: not for the software itself, but if you don't have the expertise/skills in implementing and hosting Koha you may need to engage one of the support providers that do |
| 07:28 | TriveniChandriki[m] | Any body help on koha git installation in single server multiple instances |
| 07:30 | 21.05 still working fine. After 21.11 koha version we are facing issues items modification and sip2 | |
| 07:39 | alex_ joined #koha | |
| 07:39 | alex_ | Bonjour |
| 07:47 | cait joined #koha | |
| 07:54 | lds joined #koha | |
| 08:00 | cait1 joined #koha | |
| 08:05 | thibaud_g joined #koha | |
| 08:27 | Joubu | @later tell tcohen "oh, I ctrl+c too late" There is the pre-push hook so should prevent you from pushing in that case... |
| 08:27 | huginn | Joubu: The operation succeeded. |
| 08:31 | ashimema | I don't think the pre-push hook catches -S signatures.. i.e. signed with key not just SO line |
| 08:32 | I think that's what tcohen meant | |
| 08:39 | Joubu | we should add it then ;) |
| 08:47 | ashimema: we are missing builds for 22.11 | |
| 08:47 | jenkins builds I mean | |
| 08:48 | ashimema | Oh really |
| 08:49 | What would to say we're missing? | |
| 08:50 | And yes, I agree it would be good to catch crypto signs in the prepush | |
| 08:50 | Joubu | there is no full run, only ligth runs |
| 08:50 | ashimema | Ho, |
| 08:51 | Joubu | https://jenkins.koha-community.org/ tab "supported" shows Koha_22.11_D10, Koha_22.11_D11, Koha_22.11_D11_ES7, Koha_22.11_D11_OS7 |
| 08:51 | but the dashboard has more | |
| 08:52 | ashimema | Will look when I'm back from school run |
| 08:52 | I imagine seeing are mis-labelled | |
| 08:52 | Joubu | I am on it, nevermind |
| 08:52 | ashimema | It's been a while since I properly dug on the Jenkins side |
| 08:52 | Thanks dude | |
| 08:53 | I tend to maintain the dashboard side by cloning the existing lines and replacing the version numbers.. if we change naming scheme in Jenkins things can go wrong | |
| 08:55 | Joubu | Where/where did we decide to drop support for U18? |
| 08:58 | ashimema: ok, "supported" tab must be removed actually, I am removing it. It's not maintained | |
| 08:58 | ashimema | A while ago I believe.. falling in line with when Ubuntu stopped supporting that version |
| 08:59 | But I might be wrong.. tuxayo was keeping on top of those things I thought | |
| 09:01 | Joubu | end of "standard" support is April 2023, end of life of 2028 |
| 09:03 | tuxayo: can you remove the "supported" view on jenkins please? https://jenkins.koha-community[…]g/view/supported/ | |
| 09:04 | tuxayo: If you are the one who created it | |
| 09:05 | tuxayo: nevermind, it's done | |
| 09:06 | mtj, tuxayo, tcohen, ashimema: I removed the "supported" view on jenkins, and "Enabled" is now the default view. | |
| 09:06 | fridolin left #koha | |
| 09:08 | Joubu | I have no idea who created the 22.11 jobs, but they are not correctly setup, "Koha_22.11_D12" is actually running 22.05... |
| 09:13 | ashimema | I'm confused.. I'm sure they were accurate to start with |
| 09:17 | Joubu | ashimema: Koha_22.11_D12 config is fixed, and Koha_22.11_D11 is now running the full test suite. Other jobs are correct |
| 09:18 | They are currently building with their new config | |
| 09:35 | ashimema | thanks dude |
| 10:10 | dpk_ joined #koha | |
| 10:25 | cait1 | Joubu++ ashimema++ |
| 10:28 | * ashimema | is well and truly stuck on a support call today |
| 10:28 | ashimema | can't for the life of me work out why an acquisitions endpoint isn't happy ☹️ |
| 10:30 | cait1 | REST API? |
| 10:30 | ashimema | yup |
| 10:31 | cait1 | hm :( probably can't help much then |
| 10:31 | do you have any error or so? | |
| 10:31 | * cait1 | knows acq pretty well, just not the API |
| 10:31 | ashimema | for some reason I keep getting MethodNotCoveredByTests exceptions thrown against Biblioitem.. which I understand.. it should be getting called against Biblio |
| 10:31 | but I can't for the life of me work out why! | |
| 10:31 | seems to just be this one server too | |
| 10:32 | GET /api/v1/acquisitions/orders: unhandled exception (Koha::Exceptions::Object::MethodNotCoveredByTests)<<The method Koha::Biblioitem->active_orders is not covered by tests! | |
| 10:33 | cait1 | is this a standard Koha or are there customizations that could be it? |
| 10:33 | maybe something others don't have? | |
| 10:34 | ashimema | brb.. been called into another meeting |
| 10:34 | no customisation around acq | |
| 10:34 | Joubu | no embed? |
| 10:34 | ashimema | I 'think' it might be data |
| 10:34 | yeah.. loads of embed | |
| 10:35 | it's the order recieve page.. the api call there just outright 500's | |
| 10:35 | Joubu | which ones? |
| 10:35 | tcohen | hola #koha o/ |
| 10:35 | ashimema | basket.basket_group,biblio.active_orders+count,biblio.holds+count,biblio.items+count,biblio.suggestions.suggester,fund,current_item_level_holds+count,items |
| 10:35 | cait1 | just the other person who might know heh |
| 10:36 | ashimema | it's a 21.11.05 install.. my next stab in the dark was going to be to try and bring it up to latest 21.11.x |
| 10:36 | but I'm not seeing any changes in this area since this version on the 21.11 branch | |
| 10:36 | will dig back in in a bit.. struggling to juggle calls | |
| 10:37 | Joubu | https://snipboard.io/n94elh.jpg - is this expected? The item form is no longer left aligned |
| 10:40 | ashimema | I have a vague memory I pointed that out at some point too |
| 10:40 | cait1 | yes |
| 10:40 | the labels are expected | |
| 10:40 | they match the labels on the normal item form now | |
| 10:40 | we have complaints that the short terms etc were far from the fields (or there was not enough space for long translations) - it's been left aligend for some time | |
| 10:41 | but the formatting of the item form in general is still broken in some spots with the new design :( | |
| 10:41 | bug 32758 | |
| 10:41 | huginn | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=32758 normal, P5 - low, ---, koha-bugs, NEW , Item form when receiving serial issues is misaligned |
| 10:41 | cait1 | bug 32759 |
| 10:41 | huginn | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=32759 normal, P5 - low, ---, koha-bugs, NEW , Item form when creating items on receive is misaligned |
| 10:43 | cait1 | hm you didn't mean the labels, did you? just the whole thing? |
| 10:45 | Joubu | alignment |
| 10:45 | the item form is centered, it used to be left aligned | |
| 10:47 | * oleonard | walks in and immediately walks out |
| 10:47 | tcohen | Joubu: there's no pre-push hook for GPG signed commits |
| 10:47 | Joubu | yes, we should add one then :) |
| 10:48 | tcohen | indeed |
| 10:50 | Joubu: the ktd hooks are designed to run outside the container | |
| 10:51 | there's one that calls docker | |
| 11:15 | cait joined #koha | |
| 11:26 | oleonard | there's one that calls the docker and the docker said, no more monkeys jumping on the bed. |
| 11:39 | lds_ joined #koha | |
| 12:00 | hammat_ joined #koha | |
| 12:01 | cait joined #koha | |
| 12:06 | Joubu | tcohen, ashimema: bug 31028 really needs more attention |
| 12:06 | huginn | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=31028 new feature, P5 - low, ---, martin.renvoize, Needs documenting , Add 'Report a concern' feature for patrons to report concerns about catalog records |
| 12:07 | ashimema | I wish you'd shown some interest when I wrote the stuff months ago ☹️ |
| 12:08 | I need to fix my support issues before I can revisit it | |
| 12:08 | Joubu | I am not really showing interest to be honest, just hitting bugs and conflicts :D |
| 12:08 | ashimema | but I am aware you've pointed things out so will |
| 12:08 | get onto asap | |
| 12:12 | cait1 | we'll fix all the things |
| 12:12 | alittle more worried about the patron search one tbh because that's in stable | |
| 12:12 | * cait1 | summons kidclamp |
| 12:12 | * kidclamp | waves |
| 12:14 | kidclamp | what's up? |
| 12:18 | cait1 | you broke the patron search for spanish and other double names |
| 12:18 | i think | |
| 12:18 | tcohen | kidclamp never breaks, he puts us at test |
| 12:19 | cait1 | heh, yeah,... I pondered how i could have said that in a nicer way |
| 12:19 | bug 33117 | |
| 12:19 | huginn | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=33117 normal, P5 - low, ---, koha-bugs, NEW , Patron checkout search not working if searching with second surname |
| 12:27 | kidclamp | Heh, I "fixed" searching for other libraries |
| 12:27 | Syspref? | |
| 12:28 | alex_ joined #koha | |
| 12:32 | ashimema | right |
| 12:32 | that's one support ticket down | |
| 12:32 | I'll try to have a look at your feedback properly now Joubu | |
| 12:37 | marcelr joined #koha | |
| 12:37 | marcelr | o/ |
| 12:42 | Joubu | kidclamp: shouldn't we instead of the filters for "check out" as well? |
| 12:42 | have* | |
| 12:42 | https://snipboard.io/UV6ubv.jpg | |
| 12:43 | they are actually not taken into account for autocomplete results | |
| 12:43 | kidclamp | correct |
| 12:44 | Joubu | they are actually not taken into account at all :D |
| 12:45 | kidclamp | is that true? I get differetn results with starts with or contains |
| 12:45 | Joubu | search field and search type are, not library and category |
| 12:46 | maybe that's the solution for 33117, add the filters for check out, and make them sticky? | |
| 12:46 | I am looking at fixing library and category filters | |
| 12:47 | well, add the filters for check out *and* use them for the autocomplete query | |
| 12:53 | broken for 8 years \o/ | |
| 12:56 | bug 33155 | |
| 12:56 | huginn | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=33155 normal, P5 - low, ---, jonathan.druart+koha, Needs Signoff , Category and library filters from header patron search not taken into account |
| 13:03 | cait1 | hm can't beleive it didn't work for that long... but i might always use the ones ont he left? |
| 13:04 | kidclamp: is treating different fields differently an option? | |
| 13:05 | like cardnumber, library, etc should not use contains but name parts shoud? | |
| 13:05 | kidclamp | the name parts are exactly what our libraries were complaining about |
| 13:06 | cait1 | your bug description is about cardnumber |
| 13:06 | ah,... ok... i shoudl read all | |
| 13:06 | it's clearly a regression for some of us - german too | |
| 13:07 | we also have double hyphenated double names, especially when people marry | |
| 13:07 | jzairo joined #koha | |
| 13:08 | cait1 | the normal patron search also uses contains |
| 13:08 | kidclamp | to be clear, it is still possible to achieve previous results by adding % at the start |
| 13:08 | the normal patron search follows the filters - mine seems to default to starts with | |
| 13:09 | cait1 | hm which filters? |
| 13:09 | or maybe we changed that too, I was looking at a 20.11 - that's pre new patron serach | |
| 13:09 | the filters default to contains there | |
| 13:10 | same for our 22.11 | |
| 13:10 | oh interesting | |
| 13:10 | kidclamp | matser mine is defaulting to starts with |
| 13:10 | cait1 | 22.11 : left hand fitelrs default to contians, the expanded filters on top to begins with |
| 13:11 | hm would it work as they want if we made the type of serach default configurable? | |
| 13:12 | it looks like it might | |
| 13:12 | kidclamp | I think we could affect only the autocomplete |
| 13:12 | cait1 | but the problem with the filters is also that they jump back tp default after each search, they don't stick |
| 13:12 | kidclamp | or like joubu said, make the autocomplete respect the filters |
| 13:12 | cait1 | right... this patron search and we were talkign auto-complete earlier |
| 13:12 | so separate issues | |
| 13:13 | not sure if that would be intuitive enough | |
| 13:13 | the auto complete is used in a lot of places and people might not connect that to the filter options | |
| 13:13 | most likely they won't | |
| 13:13 | unless we also start to display the options in all those places | |
| 13:13 | kidclamp | I think an autocompletecompleteness pref |
| 13:13 | :-) | |
| 13:14 | maybe a less amusing name | |
| 13:14 | cait1 | less amusing is sad, but I agree |
| 13:18 | Joubu | that should not be a pref |
| 13:18 | that's a user preference, not system | |
| 13:19 | kidclamp | explain |
| 13:21 | Joubu | distinct users from the same library could want different behaviours? |
| 13:22 | cait1 | I think a majority might be for consistent behaviour |
| 13:22 | kidclamp | I agree with Cait - easier in a consortium to tell libraries it works one way |
| 13:22 | cait1 | but I thinkt he new behaviour is the regression tbh - i just tried in 20.11 - and it is a contains there too |
| 13:23 | when i do an autocomplete for scher, my name comes up | |
| 13:23 | kidclamp | I am happy to make 'contains' the default |
| 13:23 | cait1 | I think for the stables and backport at least that woud be good |
| 13:24 | do you have feedback from the library it was changed for? | |
| 13:25 | it might be a small vs big library issue mostly | |
| 13:25 | the bigger your data... the more exact you need the search to be | |
| 13:25 | kidclamp | I think that's what it is |
| 13:26 | cait1 | coudl you include the % hint in your pref descripton please? |
| 13:27 | kidclamp | I would also like to add support for '^' as "Begins with" search, if there are no objections - on its own bug of course |
| 13:28 | or do we expect that character in names? | |
| 13:35 | cait1 | I can't imagine... |
| 13:36 | maybe it can also be checked that it's the first character in search? as a precaution | |
| 13:39 | Dyrcona joined #koha | |
| 13:44 | cait1 | Â not sure if that is a character and how it would be seen by the script |
| 13:44 | i mean a character that would make problems if it appeared in a name as it's a combined one | |
| 14:45 | caroline | Is it possible to hide the records that have no items from the opac? |
| 14:49 | cait | caroline: I am not aware of an automatism for that |
| 14:57 | caroline | thanks cait it's what I thought, but just wanted to make sure |
| 14:57 | oleonard | it seems like a logical analogue to the hidelostitems preference |
| 14:59 | cait | in our catalogs there are tons of valid records without items |
| 14:59 | traced series records, serial records with subscriptions but no items, electronic resources | |
| 14:59 | set records | |
| 14:59 | analytical records for serials and monographs (articles) | |
| 15:00 | caroline | I agree that most of the time you'd want to show records without items for those sorts... |
| 15:00 | cait | just warning you, it might get more complicated if the library hasn't thought of those |
| 15:00 | :) | |
| 15:00 | oleonard | cait: agreed, we wouldn't use it! But it seems like a logical option to have |
| 15:00 | caroline | A client was asking me, and before I said no, I wanted to make sure it was not possible :) I'm going to propose he use 942$n in batch modification |
| 15:00 | cait | ... we wanted to hide those, but not these... |
| 15:02 | I think having the option woudl make sense - wonder how it would be implemented search wise - something about the subfield for itemnumbers maybe? | |
| 15:08 | marie-luce joined #koha | |
| 15:20 | bag joined #koha | |
| 15:29 | cait | the notices editor is behaving really oddly today |
| 15:30 | half the time the contents appear empty until I reload | |
| 15:30 | anyone seen that? | |
| 15:30 | and it also happens when I save and continue - the content and subject is gone | |
| 15:36 | * oleonard-away | doesn't know but fears git will blame him |
| 15:37 | cait | notices... |
| 15:37 | any idea why this prints the biblionumber just fine: ([% entry.biblionumber %] but this gives me "No title"? [% INCLUDE 'biblio-title.inc' biblio=entry.biblionumber %] | |
| 15:37 | I have the Process line and I think the No title actually comes from the biblio-title.inc... I just don't understand why it doesn't work | |
| 15:38 | oh. I think I know. | |
| 15:38 | it wants the object I tugess | |
| 15:39 | oleonard | Yeah I ran into that just yesterday, had forgotten |
| 15:40 | cait | :) |
| 15:40 | i actually got it working now | |
| 16:15 | oleonard | I need to stop getting ideas in my head like "why not use the same table for both auth_subfield_structure and marc_subfield_structure? |
| 16:15 | caroline | but they're good ideas! |
| 16:16 | oleonard | ...but I'd love to make both pages use the same form... |
| 17:01 | fridolin joined #koha | |
| 17:02 | hammat_ joined #koha | |
| 17:56 | tcohen | am I online? |
| 17:57 | I am | |
| 18:03 | cait | you are |
| 18:09 | ashimema | Definitely offline tcohen |
| 18:10 | ;) | |
| 18:15 | tcohen | gotcha |
| 18:15 | haha | |
| 18:15 | my bouncer is doing funny things right now https://snipboard.io/DyTCP5.jpg | |
| 18:17 | https://api.koha-community.org/20.05.html | |
| 18:17 | ^^ that works, the rest of the API sites don't | |
| 18:17 | cait | I#d really be interested if someone else sees wonky things in the notices editor |
| 18:18 | it kept coming up empty again and again today for an existig notice... after reloading a few times my content came back, severl restart_all etc. nothing fixed it | |
| 18:21 | cait joined #koha | |
| 18:21 | ashimema | Weird |
| 18:23 | tcohen | I opened the WELCOME notice |
| 18:23 | expanded the Email version, all looks correct | |
| 18:24 | cait | try "save an dcontinue" |
| 18:24 | and see if it remains ok | |
| 18:24 | the initial one always worked ok for me too | |
| 18:24 | tcohen | it does |
| 18:24 | have you rebuilt the stuff | |
| 18:25 | yarn build | |
| 18:25 | inside the instance user | |
| 18:25 | ktd --shell | |
| 18:25 | yarn build | |
| 18:27 | cait | yes i did |
| 18:27 | rebult, it all looked good, just my form kept emptying out | |
| 18:27 | that should not be a css issue i think | |
| 18:27 | tcohen | maybe the URL contains a 'method=add' or smth |
| 18:27 | he | |
| 18:28 | kidding, I cannot reproduce here, unfortunately | |
| 18:28 | cait | I'll keep an eye on it |
| 18:29 | tcohen | any particular notice? |
| 18:30 | can you share the URL? | |
| 18:30 | ashimema: the API docs are broken due to a failure fetching the spec from the community repo | |
| 18:30 | we should have the build actually break in such cases... | |
| 18:33 | cait | sorry, on the other computer now |
| 18:33 | it was a new catalog notice | |
| 18:33 | CART/LIST I was working with | |
| 18:33 | but that not make a difference I think? | |
| 18:33 | we don#t eed changes in the editor for a new notice | |
| 18:36 | tcohen | well, the devil is in the details |
| 18:36 | as I cannot reproduce at all | |
| 18:38 | cait | yes, I'll try to fid out something, but not tonight :) |
| 20:54 | caroline | Does anyone have sudden XML parser problems? It seems it's a bit more sensitive now and breaks every time there is a character it doesn't like |
| 22:24 | fridolin | caroline: maybe look at |
| 22:24 | https://wiki.koha-community.or[…]s_setup_correctly | |
| 22:24 | even if on Debian | |
| 22:27 | caroline | thanks Frido! Does this change from Koha version to Koha version? The problem appeared after we updated a client from 21.05 to 22.05 |
| 22:32 | It says it looks bad on my computer... I'll try the solution tomorrow see if I can open the corrupted records/items |
← Previous day | Today | Next day → | Search | Index