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

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '25

17 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #162 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski(a)biblibre.com> --- Yep that makes sense to me. Concerning your second point, I tested it and it is the same. I did not add this to the test plan to keep it """simple""" III.1, III.2, III.3 were just requiring their specific part of the tests but do not need specific concerns -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39253] New: Issue with image koha-tmpl/opac-tmpl/bootstrap/images/koha-green-logo.svg
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '25

17 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39253 Bug ID: 39253 Summary: Issue with image koha-tmpl/opac-tmpl/bootstrap/images/koha-green-logo.s vg Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Trying to change colors for this svg file on https://deeditor.com/ gave me: Application error: a client-side exception has occurred (see the browser console for more information). In console: Uncaught SyntaxError: Invalid or unexpected token [more than once] Seeing this error in combination with svg on stackoverflow but couldnt find anything useful. Note: https://validator.nu/ does not complain about the file. https://toolplaza.app/en/tools/validate/svg tells me: SVG not valid Note that file koha-tmpl/intranet-tmpl/prog/img/picto-koha.svg looks quite a bit different than the koha-green-logo.svg too. And that toolplaza does validate the svg contents of that file! How can we correct this ? -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '25

17 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #161 from Mathieu Saby <mathsabypro(a)gmail.com> --- Before signing off, I would like a feedback from Baptiste and Victor. If they agree with my remarks I will sign off. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '25

17 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #160 from Mathieu Saby <mathsabypro(a)gmail.com> --- I followed the test plan with Baptiste help, and add a few test of my own. Everything seems ok. The test III. 4 reveals a situation that could very hypothetically be problematic, but which should be considered as a configuration inconsistency if it occurs, and not as a bug. The manual could give advice to avoid that situation : IF - check-in must be made only at the check-out library - the checked-in item must be returned its home library - the check-out was not made at the home library - the transfer from check-in library to home library is forbidden THEN the check-in is blocked at every library. Symmetrically, I suppose (but I did not test that) the check-in will be blocked if - check-in must be made only at the home library - the checked-in item must be returned its check-out library - the check-out was not made at the home library - the transfer from home library to check-out library is forbidden THEN the check-in is blocked at every library. The other situations pointed in III.1, III.2, III.3 don't seem to me "pathological". The check-in is forbidden in some libraries, but always possible somewhere, in accordance to the preferences, the circulation and the transfer rules -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38588] New: Checkin that triggers a transfer => print slip => Internal server error
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '25

17 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38588 Bug ID: 38588 Summary: Checkin that triggers a transfer => print slip => Internal server error Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1. Check in any item (e.g. 39999000012118) to trigger a transfer. Need to have a home library not in the current library. So it trigger a return-to-home transfer. 2. Print slip. 3. Exception 'Koha::Exceptions::Item::Transfer::InQueue' thrown 'Active item transfer already exists' with transfer => Koha::Item::Transfer=HASH(0x55ef3531c248) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 25996] New: Changes to debarments should be logged
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25996 Bug ID: 25996 Summary: Changes to debarments should be logged 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1 - verify borrower log is enabled 2 - click Edit on a patron 3 - on the edit page click "add a manual restriction" and enter a debarred comment, save the patron 4 - click Edit again, remove your restriction 5 - go to patron modification logs, see the log of your changes 6 - go back to the borrower checkout page, click to the Restrictions tab 7 - add a restriction 8 - delete the restiction 9 - go to patron modification logs, see there is not a log of your changes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 38397] New: Mandatory requirements in Frameworks need relationship between tag and subfield
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38397 Bug ID: 38397 Summary: Mandatory requirements in Frameworks need relationship between tag and subfield Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is a followup from Bug 36054 and tested on a 23.11 and 24.05 installation. To recreate: 1. Edit the default framework and uncheck the mandatory box for the SUBFIELD of the 005 and save. The tag itself should still be marked as mandatory. 2. Find a bib record. 3. See the 005 is not required. Save. Note: In 23.11, it is possible to delete data in the 005 and save the record in the basic editor. As of 24.05, saving the record will automatically add data to the 005 in the basic editor if it is missing in the Default framework. The record saves as it should. 4. Now edit the record again and switch to the Advanced Editor. 5. Delete the 005 tag 6. Save. Save fails and gives an error statement "Record structure invalid, cannot save." and "missing mandatory tag: 005." If a tag is marked as mandatory, the subfields should be mandatory. If none of the subfields are mandatory, should the tag still be mandatory? The mandatory requirement highlights a relationship problem between the tag settings and subfield settings. This does raise some questions on how to handle things like the 942$c. This field is mandatory regardless of what the user selects in the framework. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39656] New: syspref NotifyBorrowerDeparture : modify its description
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39656 Bug ID: 39656 Summary: syspref NotifyBorrowerDeparture : modify its description Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: e.betemps(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There is a difference between its description in staff interface and in the manual. Staff interface says : Show a notice if the patron is about to expire or has expired ___ days beforehand. The manual says : Show a notice that a patron is about to expire ___ days beforehand. Is the (staff interface) string 'or has expired' relevant ? If it's not,could it be deleted ? (If it is, I will change the manual string) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39655] New: syspref DefaultPatronSearchMethod : modifiy its description
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39655 Bug ID: 39655 Summary: syspref DefaultPatronSearchMethod : modifiy its description Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: e.betemps(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The current description of DefaultPatronSearchMethod is: (___ = the placeholder for 'Contains' or 'Starts with') ___ Enable this search method to determine whether to use 'starts with' or 'contains' for all patron searches, including auto-complete. Could this description be modified to get this : Enable this search method to determine whether to use 'starts with' or 'contains' for all patron searches, including auto-complete : ___. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 26170] New: Create "system" patrons that cannot be (easily) deleted via the web ui
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170 Bug ID: 26170 Summary: Create "system" patrons that cannot be (easily) deleted via the web ui 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment, the only way to create OAuth2 or Basic Auth credentials is to generate a user. This user can be deleted by a librarian by accident, which will break your API integration with Koha. I propose that we make some system users that cannot be deleted from the Web UI. (Or users that can be deleted by a superlibrarian, but need to be "unlocked" first or maybe have their category changed, and a warning splashed that this will likely break integrations with other systems.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 78