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

[Bug 31365] New: Plugin link location needs extra documentation so indicate where it may be found
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31365 Bug ID: 31365 Summary: Plugin link location needs extra documentation so indicate where it may be found Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: matted-34813(a)mypacks.net QA Contact: testopia(a)bugs.koha-community.org 5:25 < wajasu> my librarian looked under home->tools for Plugins, but its under Home->Administration->Plugins in 22.05 15:25 < wajasu> https://koha-community.org/manual/22.05/en/html/plugins.html#set-up 15:43 < tuxayo> wajasu: indeed! That's worthy of opening a ticket with the category "Documentation" 15:43 < tuxayo> https://bugs.koha-community.org/bugzilla3/enter_bug.cgi?product=Koha 15:52 < caroline_crazycatlady> Just so you know, it appears under tools after you have at least one plugin installed. 15:55 < tuxayo> ah :o 15:55 < caroline_crazycatlady> It's still weird because it used to be under tools even with zero plugins, hence the confusion 15:58 < wajasu> well maybe one can add (located under Administration prior to a plugin being installed) :) 16:00 < caroline_crazycatlady> Sure, the whole thing should probably be rewritten... I don't think you need to change the conf file anymore either I had enabled the koha-conf.xml <enable_plugins>1</enable_plugins> and systemctl restart memcached koha-common apache2 So now Plugins shows under Home->Administration. Maybe that can be noted in the docs https://koha-community.org/manual/22.05/en/html/plugins.html#set-up After I enabled the plugins in koha-conf.xml, my librarian couldn't find the plugins link, since the docs said it was in Tools. Plus the crazycatlady mentioned it migrates to tools once a plugin is installed. It might also be worth mentioning the need to restart memcached, koha-common (i.e. koha-plack --restart <instance>) and apache2, fothe plugin to show up after it's installed, if that is the case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 31506] New: Add "backup days" to /etc/koha/koha-common.conf
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31506 Bug ID: 31506 Summary: Add "backup days" to /etc/koha/koha-common.conf Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com koha-run-backups takes the --days argument to say how many days of backup we should keep around. The value of this is set to two in the default /etc/cron.daily/koha-common that is installed by the Debian packages. I routinely increase this value to keep more backup. One thing that can happen now is that I want to create fresh backups for all the sites on a server before doing an upgrade. So I run koha-run-backups manually, but I forget about the --days argument. Result: I loose a lot of backup! It would be nice if the default for --days could be set somewhere like /etc/koha/koha-common.conf. That way we could run koha-run-backups both from cron and manually, without the --days argument, and keep the same amount of backups either way. If --days is given as an argument, it should override the default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 27138] New: Host items are not included in Z39 results when using EasyAnalytics
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27138 Bug ID: 27138 Summary: Host items are not included in Z39 results when using EasyAnalytics Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a library enables EasyAnalytics and links two records in the catalog then the host items show on the child record. If you search for these records via Z3950 (via zebra directly or the responder) the host items are not shown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 65

[Bug 21309] New: Add flag to change password
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21309 Bug ID: 21309 Summary: Add flag to change password 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 add a flag to patron accounts that, if checked, would require the patron to sign in to their account and change their password. This option could incorporate the following functionality: * Allow patron to sign in with old password then prompt for a new password. * E-mail patron notifying them with the need to change. * When active, it would block checkouts and sip authentication until done. * Anytime a password is changed in the account, whether staff side or opac, the change would clear the flag in the patron account. * Date of change should be time stamped. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 27063] New: Allow changing which record an order is linked to
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27063 Bug ID: 27063 Summary: Allow changing which record an order is linked to Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment if the basket is still open you can update the bbliographic details of an order or overwrite the existing record via Z39.50, but if you notice that you have used the wrong record, there is no way to fix this. It would be great if it was possible to change the record an order is linked to while the basket is still open. This should explicitly allow to use a record that is already in the catalog. -- There is also a use case here for libraries using standing orders for tracking electronic resources such as series. They usually place the order on the series record. When the volumes arrive they'd like to change it so the acq information is tied to the volume. But without using items (which is not the case here for electronic resources), this is not possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 30189] New: Heading of Overdues with fines doesn't match
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30189 Bug ID: 30189 Summary: Heading of Overdues with fines doesn't match Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When going to 'overdues with fines' from the start page of circulation the heading there and in the breadcrumbs doesn't match. Heading: Circulation: Overdues at Centerville Circulation could be dropped, fines is missing. Breadcrumbs: Home Circulation Overdues at Centerville -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 23861] New: Add authorised value categories description option
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23861 Bug ID: 23861 Summary: Add authorised value categories description option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I really like the way the authorised values page looks now. I think it's much more user friendly with the descriptions and the categories all laid out and not in a drop-down. Right now, the descriptions for each category are "hardcoded" in the template. Would it be feasible to move those in the DB? That way, when we add new categories, we would be able to add our own description. For example, if I add a category for RDA media type, I would be able to add a description saying it's meant to be used with 337$a. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 20638] New: Log actions on API keys
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20638 Bug ID: 20638 Summary: Log actions on API keys 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Actions on API keys shoudl be logged and auditable (i.e. who creates the API keys, who revokes, etc). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 98

[Bug 17787] New: Suppressed items seems so still be included in number of search results
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17787 Bug ID: 17787 Summary: Suppressed items seems so still be included in number of search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: viktor.sarge(a)regionhalland.se QA Contact: testopia(a)bugs.koha-community.org We have a use case where like 99% of the collection is hidden and only a few selected items are displayed in the opac (by showing their covers up front on the main page). When going to the detail page and clicking the link for an author that has a long list of records (but only one visible in the opac) I might get indication of 63 hits in the search results and a the links to pages 1,2,3 etc for search results. Only problem is that there is actually only one result since the rest are suppressed. My guess is that the code calculating the number of hits and creating links to the pages of search results is not talking to the suppression system. I could not find any open bugs about this. Perhaps because our use of suppression is a bit of a edge case(?) I ended up "solving" the problem by removing the links on author etc. since we don't use search anyhow. I'll likely not research the issue further, but I felt I should at least report it and keep an eye out. All input is welcome. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 32209] New: Item subfields required even when supplied for each order
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32209 Bug ID: 32209 Summary: Item subfields required even when supplied for each order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using MarcItemFieldsToOrder to populate order information while staging records you can set things up to supply an itemtype, however, if the itemtype field is required, you still must select one on the items tab To recreate: See bug 32166 - use file and settings to add to basket form a staged file Note you must still populate the itemtype on the second tab -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5