March 2020 - Koha-bugs - lists.koha-community.org

[Bug 16291] New: koha-remove --purge should also delete /etc/koha/sites/instance
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16291 Bug ID: 16291 Summary: koha-remove --purge should also delete /etc/koha/sites/instance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org It would be useful if 'koha-remove --purge' also deleted a /etc/koha/sites/instance dir -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 24237] New: The 406 response on the biblios end point should be more discoverable
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24237 Bug ID: 24237 Summary: The 406 response on the biblios end point should be more discoverable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Other endpoints default to an application/json response by default regardless of the Accept headers in the request. For consistency, we should do the same on the biblios endpoint.. I'm thinking a 406 still, but with a JSON encoded error message in the body explaining the available Accept headers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 21357] New: Filter elisions from index and search terms in Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21357 Bug ID: 21357 Summary: Filter elisions from index and search terms in Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ere.maijala(a)helsinki.fi To make searching easier at least in French, it would be nice to have the default configuration handle elisions properly (e.g. l'avion). Coming up with a proposed patch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 105

[Bug 24172] New: Locale is ignored when saving season/month/day name in the database
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24172 Bug ID: 24172 Summary: Locale is ignored when saving season/month/day name in the database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Hi All, it seems the locale is completely ignored when creating numbering with season/month/day names. What I'm getting on master is that the season name is saved in English in the database, ignoring the locale completely, and depending on the page, the season name will be translated or not for display purposes in the staff interface language. (Steps 1-4 of the test plan are related to bug #20511, but I feel they are related since both have to do with locale being ignored.) Here's what I did : 0- Make sure you have at least one language other than English installed 1- With staff interface in English, create a subscription with a seasonal numbering pattern and frequency, with locale in your other language 2- Check the prediction pattern, note that the season names are in English not the locale language 3- Change the staff interface to other language, redo the prediction pattern test with locale in other language, note that the season names are in other language 4- Save the subscription 5- Receive an issue, note that the season name in the "Numbered" column on serials-edit.pl is in English 6- Save your issue 7- Switch interface in other language 8- Note that the season name on serials-collection is in other language 9- If you check the database, you will see the season name is in English, even though the subscription.locale is something else Navigating through different pages, here's what I noticed: - serials-collection.pl: display is translated - serials-edit.pl: name pulled directly from db - subscription-detail.pl: name pulled directly from db - detail.pl: name pulled directly from db - opac-detail.pl: name pulled directly from db I think the locale should be used when saving the season name in the db ensuring all displays are the same and in accordance with the option specified when creating the subscription. P.S. I'm not sure it has anything to do with it, but I noticed when choosing "French" as locale, the value saved in the db (subscription.locale) is "fre" and not "fr-FR" or "fr-CA". Would that have to do with Koha not being able to find the right translations? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 129

[Bug 16840] New: URLs for old releases are broken with every new release
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16840 Bug ID: 16840 Summary: URLs for old releases are broken with every new release Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: jsn.sherman(a)gmail.com I'm working up a nice CentOS 7 ansible role that builds Koha from the tarball release. The way you shuffle tarball upon release makes automating koha builds more difficult than it has to be, and is user hostile. When you move tarballs under old releases, you don't offer a redirect to the new location, instead you return a 404. When you publish content to the web, you should treat that URL as valid for as long as you have the associated content. In this case, you still have the content, and you know exactly where it is. Ideally, you would offer clients a 301 redirect to the new location. You should only return a 404 when you deleted content or honestly have no idea what the client is asking for. This is a general website stewardship issue, and it may not seem like the most critical thing when you are trying to get a release out the door, so I would be happy to contribute my expertise and/or time to improve this aspect of release management for Koha. Thanks! -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 16350] New: Koha version history
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16350 Bug ID: 16350 Summary: Koha version history Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: mirko(a)abunchofthings.net It would be useful to have an overview of Koha releases, maybe also indicating what is actively maintained/supported and what is not. Many projects have that on Wikipedia and/or their websites, I could not find any for Koha. I drew this awesome post-coloured ascii picture once which may or may not indicate what I mean: http://abunchofthings.net/koha/pics/koha_releases.png -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 23285] New: Add patron PATCH route
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23285 Bug ID: 23285 Summary: Add patron PATCH route Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi Patron PATCH route is not yet implemented. PUT route is not exactly overwriting all data but there are some parameters which are required. PATCH route should accept updates from one to n fields. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 24438] New: index can fail on timeout
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24438 Bug ID: 24438 Summary: index can fail on timeout Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com We have seen occasional timeouts when indexing elasticsearch, these cause the indexing to stop and fail. We should handle the response as the code indicates: 102 sub update_index { 103 my ($self, $biblionums, $records) = @_; 104 105 my $conf = $self->get_elasticsearch_params(); 106 my $elasticsearch = $self->get_elasticsearch(); 107 my $documents = $self->marc_records_to_documents($records); 108 my @body; 109 110 for (my $i=0; $i < scalar @$biblionums; $i++) { 111 my $id = $biblionums->[$i]; 112 my $document = $documents->[$i]; 113 push @body, { 114 index => { 115 _id => $id 116 } 117 }; 118 push @body, $document; 119 } 120 if (@body) { 121 my $response = $elasticsearch->bulk( 122 index => $conf->{index_name}, 123 type => 'data', # is just hard coded in Indexer.pm? 124 body => \@body 125 ); 126 } 127 # TODO: handle response 128 return 1; 129 } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 18407] New: REST API: Include renewability information on checkouts
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18407 Bug ID: 18407 Summary: REST API: Include renewability information on checkouts Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org It would be useful to have renewability information directly in the /checkouts endpoint to avoid making additional requests. However, this could be optional. Create /api/v1/checkouts/expanded endpoint to include additional data on checkouts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 17593] New: Extend circulation rules to include shelving location
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17593 Bug ID: 17593 Summary: Extend circulation rules to include shelving location Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We are in the process of moving over to Koha, and are still trying to manage all the details around this. Circulation rules are a big thing we have to tackle here. At the moment, we have multiple libraries, and within each library we have both open and closed stacks as well as multiple other segmentations, all specified as shelving locations (authorized value LOC). These locations are not always governed by the same set of rules, so it would be very helpful if the system could support LOC as a circulation rule condition alongside library, patron category and item type. >From doing a fairly brief look at the code, it seems GetIssuingRule and GetLoanLength in C4/Circulation.pm are the main points where the ruleset is retreived. There will of course be all the places calling these two functions, as well as database management parts to consider. If we were to develop some sort of extension to these rules, what would be an appropriate approach? It should certainly be an option to turn on to be used, but should we consider LOC as a starting point, or should LOC just be one many possible choices in the configuration? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12