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

[Bug 33965] New: Hide patron accounts that are for admin use only
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '26

01 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33965 Bug ID: 33965 Summary: Hide patron accounts that are for admin use only 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We should have a setting that only superlibrarians can set to hide patron accounts that regular staff should not need to alter. Test accounts, anonymous patron accounts, etc. Superlibrarians would be the only users that could alter accounts marked as such. You should not be able to mark superlibrarian accounts as hidden. Regular staff would be able to see names and card info throughout the system, but they would not be able to view the patron record. They should be shown a screen like "Admin use only." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 30795] New: Configure unwanted and mandatory borrower fields based on patron category
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '26

31 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30795 Bug ID: 30795 Summary: Configure unwanted and mandatory borrower fields based on patron category Change sponsored?: --- Product: Koha Version: master 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 It would be nice if there were a way to specify different unwanted and mandatory fields based on patron category (rather than enforcing 1 rule for all different patron categories). At the moment, I see libraries putting in junk data (like '-' or 'N/A') to get around mandatory field requirements where it doesn't make sense for certain patron categories. It makes sense to have a default rule for these fields, and then individual patron categories could be overwritten with more specific rules. -- I suppose the difficulty at the moment is that we don't choose a patron category until we're already on the add patron screen. Maybe we should be making it a multi-step process. That would have its pros and cons of course. Actually, this reminds me of another thought I've had where we could standardize CRUD forms... but I'll open another bug for that... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 34162] New: Customize required patron registration fields by patron type
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '26

31 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34162 Bug ID: 34162 Summary: Customize required patron registration fields by patron type 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: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries have different required fields by patron type. For example, regular borrowers may be required to have a birth date, but an Institution patron type would not have a birth date to enter in this field. It would be great to be able to customize the borrowermandatoryfield system preferences according to patron type. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 20582] New: Turn Koha into a Mojolicious application (?)
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '26

31 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582 Bug ID: 20582 Summary: Turn Koha into a Mojolicious application (?) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 158

[Bug 29497] New: Add ability to link authorities automatically in the advanced editor
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29497 Bug ID: 29497 Summary: Add ability to link authorities automatically in the advanced editor Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice to add the link authorities automatically button in the advanced editor. Right now catalogers must use the basic editor in order to use this option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 35953] New: Add delete_any_record cataloguing subpermission
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35953 Bug ID: 35953 Summary: Add delete_any_record cataloguing subpermission Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: wainuiwitikapark(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 36393] New: Renewal with a specific date does not take the new date due that we pick
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36393 Bug ID: 36393 Summary: Renewal with a specific date does not take the new date due that we pick Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To reproduce 1- Log in to the staff interface 1-1. Make sure you have a ciculation rule that allows you to renew 1-2. set the AllowRenewalLimitOverride system preference to Allow and SpecifyDueDate to Allow 2. Check out the item to a Borrower 5. Access the borrower's account and renew it until the limit is reached and note the due date. 6. Go to Circulation, click Renew 7. Enter the item barcode and choose a due date further than the due date from step 5 and submit 8. Click on Override limit and renew button ---> Note that the new date due is not the date that we picked in step 7 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 20958] New: Allow admins to choose data types for additional attributes
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '26

28 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20958 Bug ID: 20958 Summary: Allow admins to choose data types for additional attributes 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: hughr(a)brimbank.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently additional patron attributes are always strings. It would be really useful to be able to specify what data type an additional attribute should be when it is created, like you can specify whether it has to be unique, or is repeatable. e.g. we might want it to be a DATE, or possibly a DATETIME, or we may indeed want a STRING, or an INT, or a DECIMAL etc - it really depends on what a given library is using the attributes for, and how they might want to run reports against it. This would be a more holistic way to deal with Bug 6339. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 19336] New: Add option to fines.pl to apply maximal fine amount after delay
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '26

28 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19336 Bug ID: 19336 Summary: Add option to fines.pl to apply maximal fine amount after delay Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.bourgault(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 88

[Bug 20682] New: Authorised values should have an option to set a default
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '26

27 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20682 Bug ID: 20682 Summary: Authorised values should have an option to set a default Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: hughr(a)brimbank.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are many places in Koha where values can be chosen via a drop-down menu listing a particular authorised value. For example SUGGEST_FORMAT is used to populate the list of formats that can be selected when placing a purchase suggestion. Currently these lists appear in alphabetical order by description or OPAC description (depending on context), and the first option in the list is usually auto-selected (i.e. more or less default behaviour for a vanilla HTML <select> element). This is problematic in many circumstances as users will accidentally 'select' the first alphabetical option if they don't change anything. There should be a setting in Authorised Values to set between zero and one values per category to be the default value (probably in authorised_values.pl?op=add_form). This would then add a 'selected' attribute to the <option> tag wherever the authorised value list appears as a dropdown menu. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11