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

[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

[Bug 39622] New: Create a method for sharing 1 runtime parameter value across multiple runtime parameter placeholders
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39622 Bug ID: 39622 Summary: Create a method for sharing 1 runtime parameter value across multiple runtime parameter placeholders 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, if you want to add 1 date to a complex query at runtime, you'll probably have to make 2+ runtime parameters, so you'll get prompted for 2+ values at runtime, and you'll just have to remember that they need to be identical. What if we had a way of tagging a runtime parameter, so that you only got asked for it 1 time? That could improve UX and reduce human error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 39638] New: Notice display modal should respect 'email' message transport type
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39638 Bug ID: 39638 Summary: Notice display modal should respect 'email' message transport type Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 39410 So, we got another step closer to displaying accurate renders of generated notices in a modal from the user notices pages with bug 39410.. However, whilst this properly dissociates the stylesheets used in the staff client from the notice preview modal using shadow DOM.. it does not yet mimic the escaping and reduced function set of HTML that email clients use to render mail. We should consider message transport type when rendering the display and for email type notices, we should parse them in the same way an email client would. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39410 [Bug 39410] Notice display modal should use shadow dom -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 39649] New: Add option to hide "Availability" facet in search results
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39649 Bug ID: 39649 Summary: Add option to hide "Availability" facet in search results Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.adamyk(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org After running a search in the staff client or OPAC, there is an "Availability" option at the top of search facets that allows you to "Limit to records with available items." Some libraries have bibliographic records without items attached that they want to show as available (electronic resources, for example). It would be helpful to have the ability to hide this availability toggle with a system preference. Even better would be the option to hide in the OPAC but not in the staff client, if possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 39639] New: Branch hours and calendars need to work together
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '25

15 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39639 Bug ID: 39639 Summary: Branch hours and calendars need to work together 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We can define branch hours under the branches settings, but these have no connection to the branch holidays defined in the calendars under the tools. The calendar should take into consideration any hours defined under branches, and show closed dates defined in branches, and act accordingly. The calendar should primarily be used to define exceptions to those hours. We should also consider having the calendars moved to the branches. It makes more sense to have this information connected directly with the branches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 39641] New: dateformat options
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '25

15 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39641 Bug ID: 39641 Summary: dateformat options 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Wondering if there could be more options for date format displays, including: January 1, 2025 Wednesday, January 1, 2025 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39640] New: timeformat shows 12 format with leading zero
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '25

15 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39640 Bug ID: 39640 Summary: timeformat shows 12 format with leading zero 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Is there a reason the 12 hour format needs to have a leading zero? This is not common, at least for the US. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0