May 2025 - Koha-bugs - lists.koha-community.org

[Bug 23260] New: Anonymize (remove) patron data from items_last_borrower
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23260 Bug ID: 23260 Summary: Anonymize (remove) patron data from items_last_borrower Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Increase level of patron privacy by removing patron information from the items_last_borrower table after a set period of time. Adjust the batch_anonymize cronjob to also remove data from the items_last_borrower table when the data is more than x days old (runtime option) but not if the item is lost, damaged, or withdrawn. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 336

[Bug 29285] New: UI tests: Selenium 4 support
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29285 Bug ID: 29285 Summary: UI tests: Selenium 4 support Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org Now v4 is the default when getting the docker image selenium/standalone-firefox . For Selenium 4, the maintainer of our current perl bindings wrote another client: https://metacpan.org/pod/Selenium::Client -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 33840] New: UpdateItemLocationOnCheckin needs a duration and library parameters
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33840 Bug ID: 33840 Summary: UpdateItemLocationOnCheckin needs a duration and library parameters 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice if we could define in UpdateItemLocationOnCheckin how long the change takes effect. Either add a |0 for indefinite, or |60 for 60 minutes (enter the duration in minutes. Maybe also have a |[BRANCH,ETC] or |[ALL] parameter to indicate what branches this would affect. That way, you could specify which branches to apply which timings to. The reason for this is that the reset to permanent is currently done through a cron, so we can't see this in settings, and it is global. It affects everyone. Some libraries return items to the shelf sooner than others. We could streamline this to adjust to each libraries reshelving rate. I guess the only issue would be the trigger for this. Should a cron job be checking these updates, and should there be a minimum on how often this cron runs so that it doesn't bog down the system? Would it bog down the system looking for items in shelving location at a branch? Should it be limited to hours and not minutes? Also, should UpdateItemLocationOnCheckin be left as a global setting, and should we have a branch level setting in the branches setups? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37381] New: Suggestion mandatory fields needed in staff interface
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37381 Bug ID: 37381 Summary: Suggestion mandatory fields needed in staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It is possible to mark fields mandatory in the purchase suggestion form for the OPAC with OPACSuggestionMandatoryFields. It should also be possible to mark fields mandatory for the purchase suggestion form in the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 38202] New: Add table configuration and export options to table of subscriptions
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38202 Bug ID: 38202 Summary: Add table configuration and export options to table of subscriptions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The table of subscriptions in the serials module has sorting and filter options, but is missing table configuration and export. It would be great if these options could be added. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 28846] New: MarcRecordFromNewSuggestion needs mapping to biblioitems.itemtype
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28846 Bug ID: 28846 Summary: MarcRecordFromNewSuggestion needs mapping to biblioitems.itemtype Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In C4::Suggestions, MarcRecordFromNewSuggestion uses mapping to biblioitems.itemtype : https://git.koha-community.org/Koha-community/Koha/src/commit/e9428f662fe2e… But this Koha to MARC mapping may not exists when itemtype is on item level. Same for biblio.autor, even if unlikely. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 35200] New: Patron attributes should be translatable
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35200 Bug ID: 35200 Summary: Patron attributes should be translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N 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: frederic(a)tamil.fr I ran into this problem with a library that needed a lot of patron attributes, and they use self-registration. Their OPAC is in fr-CA, en, and es-ES. I created the patron attributes with labels in french. But then I had to write JQuery to translate them in en and es-ES. This is a sample of the js (I'm not a developer, so it might not be great, but it seems to work) $("html[lang='en'] body#opac-patron-registration a[name='patron-attr-start-1_NOM'] + li label").text("Baby's surname:"); $("html[lang='en'] body#opac-patron-registration a[name='patron-attr-start-2_DOSSIER'] + li label").text("Baby's file number:"); $("html[lang='es-ES'] body#opac-patron-registration a[name='patron-attr-start-1_NOM'] + li label").text("Apellido del bebe:"); $("html[lang='es-ES'] body#opac-patron-registration a[name='patron-attr-start-2_DOSSIER'] + li label").text("Número de expediente del bebé:"); I wonder if it would be possible to use the same process as translating the itemtypes (entry in localization table). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 38136] New: Refactor database translations (alternative)
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38136 Bug ID: 38136 Summary: Refactor database translations (alternative) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com This has the same goals of bug 24975 but with a different approach -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 85

[Bug 39900] New: Add public REST endpoint for additional_contents
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39900 Bug ID: 39900 Summary: Add public REST endpoint for additional_contents Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 36762] New: Item not transferred correctly when there is a pending hold
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36762 Bug ID: 36762 Summary: Item not transferred correctly when there is a pending hold Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha is doing some dumb stuff when one attempts to transfer an item that could fill a pending hold. To recreate: 1 - be logged in at Branch A 2 - have a bib with 1 holdable item at Branch A 3 - place a hold for pickup at Branch B 4 - confirm hold shows on Holds to Pull and Holds Queue 5 - go to Circulation > Transfers and attempt to send your item to Branch C 6 - Koha gives you three options. Pick the first one: "Transfer to Branch B." This is the hold pickup branch, not the branch you selected for your transfer 7 - Koha tells you it has transferred the item to Branch C (the branch you did select for your transfer) 8 - go to detail.pl for your title, confirm the holdings table says "there is an item level hold" on your item 9 - click to the Holds tab for your title, confirm the hold claims to be in transit 10 - query the branchtransfers table, confirm no transfer was created 11 - query reserves and confirm your hold has found=T, itemnumber=[your item], and item_level_hold=0 12 - Back on the title, attempt to revert transit status, confirm the Revert button doesn't do anything At step 6, Koha should offer to transfer to the indicated transfer-target, rather than the hold pickup branch. Then it should actually generate the transfer and should not insert the itemnumber into the reserves table or update reserves.found. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38