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

[Bug 35228] REST API: Restricted staff users can see patron extended attributes (not exposed via UI)
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '24

06 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35228 --- Comment #3 from David Cook <dcook(a)prosentient.com.au> --- I feel like there is a different bug report for this one too... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35227] REST API: Restricted staff users can see patron info (not exposed via UI)
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '24

06 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35227 --- Comment #7 from David Cook <dcook(a)prosentient.com.au> --- I think this one might not be valid anymore. I think bug 29509 may have fixed it? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 33305] New: Standing orders: Allow to link received item to another bibliographic record on receive
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33305 Bug ID: 33305 Summary: Standing orders: Allow to link received item to another bibliographic record on receive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: michaela.sieber(a)kit.edu At the moment we use standing orders for multi-volume and series ordering mostly. The order is placed on the set or traced series record. When a part of the series is delivered and received, the order line will still be linked to the set records. This makes all acquisition information appear on the set record, instead of the parts. If you are using items, you can use the "attach item" feature, to change it to the record of the part, but this means a lot of additional clicks. It will also not work if you are not creating items in acq. It would be nice, if you could link the received order line to the correct part as part of the receiving process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36216] New: Hide Show checkouts/charges to guarantor when not necessary
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36216 Bug ID: 36216 Summary: Hide Show checkouts/charges to guarantor when not necessary Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com In the patron file (moremember.pl), there is always "Show checkouts to guarantor" and "Show charges to guarantor", even if the library doesn't use the guarantor feature. If AllowStaffToSetCheckoutsVisibilityForGuarantor and AllowPatronToSetCheckoutsVisibilityForGuarantor are both set to "Don't allow", or if the patron has no guarantor, I think the "Show checkouts to guarantor" field should be hidden. Same for AllowStaffToSetFinesVisibilityForGuarantor and AllowPatronToSetFinesVisibilityForGuarantor. If both are set to "Don't allow" or if the patron has no guarantor, the "Show charges to guarantor" should be hidden. I'm thinking especially of academic libraries and special libraries, this is useless information that shows in the patron file. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 37571] New: Redirect from Privacy policy after consent registered
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37571 Bug ID: 37571 Summary: Redirect from Privacy policy after consent registered Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aude.charillon(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When using the PrivacyPolicyConsent preference, the page opac-patron-consent.pl appears when patrons first login to the OPAC. Once they have saved their consent, the message "Your consent was registered on YYYY-MM-DDT00:00:00." appears above the Save button and that Save button is disabled. This is confusing for some patrons, who expect to be redirected to their account summary after seeing the confirmation message. If redirecting is not an option, clarifying the message would be helpful - e.g., "Your consent was registered on YYYY-MM-DDT00:00:00 - you may now use the website." -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37565] New: bulkmarcimport should have an option to prevent record indexing
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37565 Bug ID: 37565 Summary: bulkmarcimport should have an option to prevent record indexing Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When loading large files we sometimes want to have speed emphasized over completeness - it would be nice to be able to skip indexing and manually reindex after a large record load -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37018] SQL injection using q under api/
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37018 --- Comment #159 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Similarly just wondering if + if ( ref $element eq 'ARRAY' && $element->[0] eq '-and' ) { + _validate_query( $element->[1] ); this catches everything ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37018] SQL injection using q under api/
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37018 --- Comment #158 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Good work, here guys! When I am looking at the code of _validate_query, I am wondering if constructs like priority => [ { '=', 2 }, { '>', 5 } ] are parsed correctly? It seems that the inner hashes go recursively back into the routine, but the operators = and > here are viewed as field names and wont be checked with _validate_operator. Or am I misreading something? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37507] New: Koha explodes when trying to apply discount higher than amount of manual invoice
by bugzilla-daemon＠bugs.koha-community.org 04 Aug '24

04 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37507 Bug ID: 37507 Summary: Koha explodes when trying to apply discount higher than amount of manual invoice Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org When applying discount higher than amount of manual invoice Koha explodes with a message: "Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Amount to reduce (100) is higher than original amount (10.000000)' at /usr/share/perl5/Exception/Class/Base.pm line 88". To reproduce: 1. Go to the patron -> accounting 2. Create manual invoice with positive amount (e.g. 10). Click Save. 3. In Transactions tab click 'Apply discount' button and enter discount to apply higher than amount entered in p. 2 (e.g. 100). 4. Koha explodes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36003] New: Printing list from OPAC shows "Cookies" when CookieConsent enabled
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '24

03 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36003 Bug ID: 36003 Summary: Printing list from OPAC shows "Cookies" when CookieConsent enabled Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If system preference CookieConsent is set to "Required", the word "Cookies" appears at the bottem left on the last page, under the last result, when printing a list from the OPAC. Funny, but not desirable. Not sure if similar to bug #12260. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18