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

[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 25825] New: Allow Claim Return function to be controlled by permissions
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '26

25 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25825 Bug ID: 25825 Summary: Allow Claim Return function to be controlled by permissions Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be helpful to have a way to control which users are able to initiate and resolve a claim return. Some libraries will only want certain levels of staff to be able to initiate the Claim Return, and likewise, only certain staff should be able to resolve it. Perhaps a permission for each of those functions? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[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 25384] New: Label maker font list is not configurable
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '26

24 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25384 Bug ID: 25384 Summary: Label maker font list is not configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The label maker font list is hard-coded to 12 arbitrary choices. It would be better if we could configure the font choices in the user interface (since we can already configure the truetype font files in koha-conf.xml). -- You are receiving this mail because: You are watching all bug changes.

1 35

[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