August 2016 - Koha-bugs - lists.koha-community.org

[Bug 16631] New: Show groups/categories of reports to authorized staff
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '26

03 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16631 Bug ID: 16631 Summary: Show groups/categories of reports to authorized staff Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful to have reports that are specific groups/categories to be authorized under the reports permissions in a patron account. Not everyone wants to see everyone else's reports, some are similar but are not. Some are for superlibrarians to test, and are not ready for use. It would be great if we could specify groups and even subgroups in the permissions that the staff could access, or specify all groups. All groups should be the norm for a superlibrarian. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 301

[Bug 17015] New: New Koha Calendar
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17015 Bug ID: 17015 Summary: New Koha Calendar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: mehdi.hamidi(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org We are trying to create a new Koha calendar system. The one available right now is way too slow. This is the first patch of the calendar, it doesn't affect the functioning of the current calendar, but it works in parallel with it. Instead of having multiple tables for the holidays, we created one table, called discrete_calendar. This table contains the dates,branchcode, opening/closing hours, a note about the holiday and whether the library is open or not. The script misc/generate_discrete_calendar.pl fills the table discrete_calendar based on tables : repeatable_holidays, special_holidays, openinghours and branches. The script, by default, will add 2 years from the past and 1 year in the future in the table discrete_calendar. It also has an option to added more than 1 year in the future. The script misc/cronjobs/add_days_discrete_calendar.pl will add days in the future in the table discrete calendar. A day's opening and closing hours will be based on the same weekday from the week before. It will also check if the same day from last year was a holiday, if so, this will be counted as a holiday. The script makes sur there's at least 1 year in the future. So if it hasn't ran for 8 days, 8 days will be added in he future the next time the script is executed. There's also an atomic update to create the table. The current options are not final and they can be changed for convenience. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 529

[Bug 16773] New: Deleting an EDIFACT message should ask for confirmation
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16773 Bug ID: 16773 Summary: Deleting an EDIFACT message should ask for confirmation Change sponsored?: --- Product: Koha Version: master 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 When deleting an EDIFACT message, it should ask for confirmation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 16291] New: koha-remove --purge should also delete /etc/koha/sites/instance
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16291 Bug ID: 16291 Summary: koha-remove --purge should also delete /etc/koha/sites/instance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org It would be useful if 'koha-remove --purge' also deleted a /etc/koha/sites/instance dir -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 16840] New: URLs for old releases are broken with every new release
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16840 Bug ID: 16840 Summary: URLs for old releases are broken with every new release Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: jsn.sherman(a)gmail.com I'm working up a nice CentOS 7 ansible role that builds Koha from the tarball release. The way you shuffle tarball upon release makes automating koha builds more difficult than it has to be, and is user hostile. When you move tarballs under old releases, you don't offer a redirect to the new location, instead you return a 404. When you publish content to the web, you should treat that URL as valid for as long as you have the associated content. In this case, you still have the content, and you know exactly where it is. Ideally, you would offer clients a 301 redirect to the new location. You should only return a 404 when you deleted content or honestly have no idea what the client is asking for. This is a general website stewardship issue, and it may not seem like the most critical thing when you are trying to get a release out the door, so I would be happy to contribute my expertise and/or time to improve this aspect of release management for Koha. Thanks! -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 16350] New: Koha version history
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16350 Bug ID: 16350 Summary: Koha version history Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: mirko(a)abunchofthings.net It would be useful to have an overview of Koha releases, maybe also indicating what is actively maintained/supported and what is not. Many projects have that on Wikipedia and/or their websites, I could not find any for Koha. I drew this awesome post-coloured ascii picture once which may or may not indicate what I mean: http://abunchofthings.net/koha/pics/koha_releases.png -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 16994] New: Import and export MARC modification templates
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '26

17 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16994 Bug ID: 16994 Summary: Import and export MARC modification templates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Configuring a complicated MARC modification template can be a tedious job, so it would be nice to be able to import and export them the way we can with MARC frameworks. This would also facilitate sharing between libraries. -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 15685] New: Allow creation of items (AcqCreateItem) to be customizable per-basket
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '26

15 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15685 Bug ID: 15685 Summary: Allow creation of items (AcqCreateItem) to be customizable per-basket Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: jweaver(a)bywatersolutions.com Reporter: jweaver(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: nicole(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 119

[Bug 15997] New: Hold Ratios for ordered items doesn't count orders where AcqCreateItem is set to 'receiving'
by bugzilla-daemon＠bugs.koha-community.org 15 Sep '26

15 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15997 Bug ID: 15997 Summary: Hold Ratios for ordered items doesn't count orders where AcqCreateItem is set to 'receiving' Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, the hold ratios script only counts on order items where the record item is created at the time the order is placed, and not if the item is created when the item is received. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 16207] New: Incorporate circulation and fine rules for library groups
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16207 Bug ID: 16207 Summary: Incorporate circulation and fine rules for library groups 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I think we could simplify circulation and fine rules by incorporating library groups into the mix. For example, I have 27 libraries, and 8 of them follow the same set of rules that are different from the defaults. So, what if instead of cloning these special rules to 8 different libraries (and who knows how many other duplicated sets of rules there are), we defined a set of rules for a library group. If the library is part of that group, it goes by those rules. I don't know if we want to use the same library groups that are already defined in the libraries and groups, or if we want to create a unique Circ rule group. Because, there is always the chance that one or more of the libraries in the 8 that are grouped together by affiliation or region could have a slightly different set of rules. However, I think rules by groups would make managing rules far less complicated than managing groups of cloned rules. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15