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

[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 26573] New: Limit patron attribute types to more than one patron category
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '26

03 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26573 Bug ID: 26573 Summary: Limit patron attribute types to more than one patron category Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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: gmcharlt(a)gmail.com Currently, Koha doesn't allow to limit a patron attribute type to more than one patron category. Let's say I have a patron attribute type STUDENTID, and I want to limit this attribute to the categories "undergrad students" and "grad students". I have to create two different patron attribute types. To replicate: 1) Go to Administration > Patron attribute types 2) Create a new patron attribute 3) Note that the "Category" field is a dropdown and you can't choose more than one patron category to assign this attribute type to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94

[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

[Bug 20813] New: Revamp user permissions system
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20813 Bug ID: 20813 Summary: Revamp user permissions system Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha's current user permissions system is a bit convoluted and limited due to it's legacy where the permissions system was a simple set of flags. A second layer of sub-permissions were later added complication and obfuscation to the system. We should revamp the permissions system to be a more modern system and open the path to having unlimited nesting of sub-permissions instead of shoe-horning sub-permissions into the limited system we have. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 19642] New: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '26

30 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19642 Bug ID: 19642 Summary: If autoMemberNum is enabled, we should just ignore cardnumber entry in BorrowerMandatoryField Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 19225 proposes a warning for users that the config is wrong. I propose instead, we should just ignore that field if automembernum is enabled (since it autocalculates and becomes mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 24608] New: Allow modification of checkout due date
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24608 Bug ID: 24608 Summary: Allow modification of checkout due date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently it is not possible to modify a checkout's due date. This bug proposes to allow such an action. It is only proposed to allow modification of a due date *forward* at this stage as moving a due date backwards may involve additional complication that will require further thought. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 71

[Bug 21482] New: Create a "landing page" for ILL
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21482 Bug ID: 21482 Summary: Create a "landing page" for ILL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Currently, when you go to the ILL module, the first iew is of all ILL requests. This can be a lot of data, and take several seconds to load, and I doubt a lot of people will want the full list. So maybe we could have some sort of intermediate page with links to selections of request, based on their status, type etc. At it's simplest this could just be a page that displays the contents of a syspref, and that syspref could then be filled with HTML and links to filtered views of ILL requests. If the syspref is empty, the intermediate page could redirect to the full view, as it is today. A more advanced version would have a GUI to configure the links, order them, give them names etc. Thougts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19