December 2023 - Koha-bugs - lists.koha-community.org

[Bug 26355] New: Tie account renewals to patron modification requests
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 Bug ID: 26355 Summary: Tie account renewals to patron modification requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Allow patrons renewal reminders to link to the patron modification requests, asking them to review their information and make any any necessary updates if necessary, but acknowledging that the information is up to date. Create a check-box stating that they have reviewed all their information, and it is accurate and up to date (if no changes are made). Perhaps this check-box only shows when their account is due for renewal. -- You are receiving this mail because: You are watching all bug changes.

1 256

[Bug 26261] New: Split calendar.inc into include file and JavaScript file
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26261 Bug ID: 26261 Summary: Split calendar.inc into include file and JavaScript file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21156 Now that we have JavaScript internationalization there's no need to have strings defined in an include file like calendar.inc. I propose that we trim calendar.inc down to only those things which require template processing and move the rest of the JavaScript into its own JS file. This would allow us to do proper linting and allow browsers to cache the file. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21156 [Bug 21156] Internationalization: plural forms, context, and more for JS files -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 18410] New: Koha should use cool URIs
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18410 Bug ID: 18410 Summary: Koha should use cool URIs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Right now Koha use a very volatile URI scheme. If we seek having not ephemeral URIs they should be completely different. Take a look to this article from 1998 of a guy called Tim Berners-Lee: "Cool URIs don't change" https://www.w3.org/Provider/Style/URI A normal Koha URI looks like this: https://catalog.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumb… This URI is doomed to die in the short term, is not designed thinking in long-term. We have a lot of information about the tools and technical things used to put it there, like "cgi-bin", "koha" and "pl". Is not even consistent about using always en_US (american English): "/cgi-bin/koha/cataloguing/addbooks.pl" (cataloguing != cataloging). As the article say we shouldn't forget about domain name. We could encourage the use of more permanent words like "catalog" for the host part of the FQDN. PS: This may be related to the robust RESTful URI. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 25667] New: Add field for items.notforloan_on to record when a notforloan status is applied
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '26

15 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25667 Bug ID: 25667 Summary: Add field for items.notforloan_on to record when a notforloan status is applied Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We record lost_on and damaged_on. Can we record notforloan_on, too? It'd be helpful for various reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 34626] New: Add waiting since date to holdswaiting patron message
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34626 Bug ID: 34626 Summary: Add waiting since date to holdswaiting patron message 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com On moremember.tt and ciculation.tt there will be a message if the patron has any waiting holds. This message displays the date the hold was placed on (reserves.reservedate) and the date it will wait until ( reservedate.expirationdate ). Some libraries would like to add the 'Waiting since' date. ( reservedate.waitingdate ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 32756] New: Additional fields: Allow additional fields to be defined as links
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32756 Bug ID: 32756 Summary: Additional fields: Allow additional fields to be defined as links 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, michaela.sieber(a)kit.edu Blocks: 32751 Sometimes you will want to link from Koha to external pages. For example you might want to link from your subscription to the vendor's page for the serial or from your basket to your order on the vendor's website. For this it would be nice if you could configure additional fields to be links. It would be especially nice if it allowed you to specify a link with a place holder, that is then entered into the field, creating the link. For example your configuration could be: [x] Is a link Link structure: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id={data} Link text: Bug {data} Then in the form, you'll just enter the number: 32751 And on all pages that display the link, this would create a link to: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32751 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32751 [Bug 32751] [Omnibus] Extend, improve and standardize additional fields -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32327] New: When replacing bib record via z39.50, only 1 ISBN should be searched and it should be normalized
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '26

14 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32327 Bug ID: 32327 Summary: When replacing bib record via z39.50, only 1 ISBN should be searched and it should be normalized Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The replace via z39.50 function pre-populates the z39.50 search form with values from the existing bib. Koha just pastes in the contents of biblioitems.isbn, which means it very often pre-populates that field with a value that will never find anything. If the existing record has more than 1 ISBN, the prepopulated form will list them all, pipe-separated. This search will always return no results, even when either ISBN returns results successfully on its own. If the existing record contains a parenthetical note about binding, that search will generally fail as well. We should only put the first ISBN from the record into the search form and we should strip out any binding note or other fluff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 28915] New: MARC Modification Templates should allow specification of a position or range within a control field
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28915 Bug ID: 28915 Summary: MARC Modification Templates should allow specification of a position or range within a control field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When dealing with the MARC Leader, 008, and other fixed length control fields, it would be nice to be able to make the modification templates look at, match on, and alter only a specific position or range. For example, suppose I have several records in which I want to change the 008 position 33 (Literary form) from a 0 to a 1 (nonfiction to fiction). Currently I could tell my modification template to update the 008 of every record I point it at where the character in position 33 is a 0 (using regex to match only that specific character). But then there's no way to change ONLY that character and preserve the rest of the field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 144

[Bug 34223] New: ILL status filter does not load immediately after selecting a backend filter
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34223 Bug ID: 34223 Summary: ILL status filter does not load immediately after selecting a backend filter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com CC: pedro.amorim(a)ptfs-europe.com Selecting a backend filter in ILL is required in order for the status filter to become enabled. Once a provider is chosen in the backend filter, it takes the status filter around 7s to populate instead of populating immediately. This is confusing to staff members and can also disrupt the workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 34058] New: ILL - Left filters not considering all terms in input
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '26

13 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34058 Bug ID: 34058 Summary: ILL - Left filters not considering all terms in input 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: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 22440 To reproduce, on k-t-d: 1) Run bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.…) 2) Create a FreeForm ILL request and input 23529000035676 in the cardnumber, that's "Henry Acevedo". 3) Go back to the ILL list table, input "henry" in the bottom "Patron" filter input and press the "Search" button, notice it fetches the request correctly. 4) Now do the the same search but with "henry acevedo", notice the request is not retrieved. The same issue also happens in the "keyword" filter input. Info: patron-search.inc is already doing what we need, but for patrons left side filters, it's handling all the patterns present in the #search_patron_filter input and adding each of those to the query, we need something similar here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22440 [Bug 22440] Improve ILL page performance by moving to server side filtering -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44