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

[Bug 21459] New: Allow migrating requests between ILL and purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21459 Bug ID: 21459 Summary: Allow migrating requests between ILL and purchase suggestions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no One library would like to be able to take a purchase suggestion and turn it into an ILL request. And to take an ILL request and turn it into a purchase suggestion. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 24125] New: Deleting an authority clears the record heading
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '26

01 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24125 Bug ID: 24125 Summary: Deleting an authority clears the record heading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Find a record with an author linked to an authority 2 - Get that authority number 3 - Browse to tools->batch record deletion 4 - Select authorities and enter that authority id 5 - Delete the authority 6 - View the record, the 100 field has been cleared -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[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 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

[Bug 20784] New: Capture more changes in Logs
by bugzilla-daemon＠bugs.koha-community.org 26 Mar '26

26 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20784 Bug ID: 20784 Summary: Capture more changes in Logs Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to have an Administration Log. A log that tracks changes (add/modify/deletes) to branch information, itemtype information, circ rules, authorised_values (others areas). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 18948] New: Elasticsearch - Reindexes should use aliases to avoid down time while reindexing
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18948 Bug ID: 18948 Summary: Elasticsearch - Reindexes should use aliases to avoid down time while reindexing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This patchset aims to add the ability to leverage the ES alias feature during a reindex - when doing a full reindex or a deletion the indexer will look for an existing index under the alias - if not found it will create a new one, if found it will index into a new index and point the alias there when done and then delete the old index. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 23898] New: New data to share on HEA
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23898 Bug ID: 23898 Summary: New data to share on HEA Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.poulain(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Some ideas of thing that could be shared on HEA for statistics purposes: - adding some statistics like "intranetuserjs yes/no" => yes if there's something, no if it's empty ? (intranetuserjs, opacuserjs, opac & intranet css, opacheader, opacnav, opacbottom). - For sysprefs *XSLT* => we could send "empty/default/local". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 21779] New: Holds history doesn't show where hold placed
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '26

24 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21779 Bug ID: 21779 Summary: Holds history doesn't show where hold placed Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: siobhancottam(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The Holds history tab doesn't show the same information as the modification log e.g. if the reservation was placed in the OPAC or staff client. It is possible to find this information from the log viewer, but not from a patron record modification log as this doesn't show holds at all. This is time-consuming to find the relevant hold if you don't already know the approximate date when the hold was placed. The system log uses the reserve ID as the Object, which is presumably why it doesn't show in the Patron log where their borrowernumber is the Object no. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8