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

[Bug 28907] Potential unauthorized access in public REST routes
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28907 --- Comment #70 from Paul Derscheid <paul.derscheid(a)lmscloud.de> --- Created attachment 179000 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179000&action=e… Bug 28907: [With corrected bug id] REST - Remove allow-owner from public password route To test: 1. prove t/db_dependent/api/v1/patrons_password.t 2. Apply patch 3. prove t/db_dependent/api/v1/patrons_password.t Observe success in both cases. https://bugs.koha-community.org/show_bug.cgi?id=28907 Signed-off-by: Victor Grousset/tuxayo <victor(a)tuxayo.net> Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39240] New: Configure search fields for Z39.50 searches in OCLC and SkyRiver
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39240 Bug ID: 39240 Summary: Configure search fields for Z39.50 searches in OCLC and SkyRiver Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: jeanne.mauriello(a)mainlib.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We are migrating to Koha on March 24, 2025. Our library consortium uses both OCLC and SkyRiver for Z39.50 searches. In Koha we need more search options. For OCLC we need to be able to search on UPC, OCLC number, and publisher number. OCLC does not have a specific UPC index, so it would need to be mapped differently. In Polaris we use the "other system number" option. We would need the same search options in SkyRiver, with the exception of OCLC number. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 28907] Potential unauthorized access in public REST routes
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28907 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the|25.05.00,24.11.02,24.05.07, | release notes|23.11.12,22.11.24 | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28907] Potential unauthorized access in public REST routes
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

1 0

[Bug 39239] New: Add an optional default manageddate filter to speed up loading suggestions
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39239 Bug ID: 39239 Summary: Add an optional default manageddate filter to speed up loading suggestions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Although you can archive suggestions and make the performance a bit better, it still takes quite long to load the suggestions page. I am proposing here to add a pref that controls the initial manageddate_from filter to further control the number of loaded suggestions. After loading the user can always change the filter. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 39251] New: Link to purchase suggestion needs &op=show added to the URL to work fully
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39251 Bug ID: 39251 Summary: Link to purchase suggestion needs &op=show added to the URL to work fully Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org To compose the link to a specific suggestion so that clicking on it takes the user right into the suggestion, it is necessary to add &op=show to the end of the url (as in cgi-bin/koha/suggestion/suggestion.pl?suggestionid=5&op=show). This is unlike any other id-based url I know (as in cgi-bin/koha/catalogue/detail.pl?biblionumber=1658434 for example). As SHOW is an SQL keyword, writing the CONCAT statement was tricky, but this worked: [...]suggestionid=', suggestionid, '&op=',CONCAT('sh','ow'). Ideally the link would work like other id-based urls in Koha, and not need the 'show' string added. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Michaela Sieber <michaela.sieber(a)kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clemens.tubach(a)kit.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39249] New: Link to manual for system preferences that are documented there
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39249 Bug ID: 39249 Summary: Link to manual for system preferences that are documented there Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de There's possibility to link from system preferences in Koha to their description in the manual, if they are documented in the manual. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 36779] New: Automatic renewal column doesn't always populate correctly when editing
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36779 Bug ID: 36779 Summary: Automatic renewal column doesn't always populate correctly when editing Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If I'm editing a rule with Yes in the 'Automatic renewal' column and then select to edit a different rule that has No in the 'Automatic renewal' column without saving the first rule, Yes 'sticks'/remains populate for the second rule. To recreate: 1. Select Edit on a rule with Yes in 'Automatic renewal'. Note that Yes populates (as it should) in the editing line. 2. Without saving any changes to the rule selected above, click Edit on a rule with No in the 'Automatic renewal' column. Note that Yes still shows in the 'Automatic renewal' column, even though other values have populated from the second rule you selected to edit. If a library doesn't notice this, they could accidentally set rules for automatic renewal when making other unrelated edits. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 33361] New: Renewals prevented on items where there is an item level hold on another item on the record
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33361 Bug ID: 33361 Summary: Renewals prevented on items where there is an item level hold on another item on the record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: Ability to override holds is needed Find/create a record with 2 items Checkout item A to a patron Place an item level hold on B for another patron Item A cannot be renewed Override renewal to renew the item It gives you a new due date but doesn't actually update the item. This also happens with autorenewals being blocked when there is an item level hold on another item on the record. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5