November 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 17656] New: Irregularities in serial prediction pattern are planned only for the current year
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '26

23 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17656 Bug ID: 17656 Summary: Irregularities in serial prediction pattern are planned only for the current year Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When you se, through test prediction pattern, a serial pattern including planned irregularities (for example a 1/month serial that you know there's no issue on july), this is only valid fot the current subscription. Over the next renewal, you will have to set it again which is very tedious. We should be able to configure this in the long run (as it was possible in previous version of Koha before 3.14, I think) Olivier Crouzet -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 420

[Bug 17385] New: Add custom export notices
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17385 Bug ID: 17385 Summary: Add custom export notices Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: bouzid.fergani(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl this patch, add custom export notices using xslt. -- You are receiving this mail because: You are watching all bug changes.

1 448

[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 17593] New: Extend circulation rules to include shelving location
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17593 Bug ID: 17593 Summary: Extend circulation rules to include shelving location Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We are in the process of moving over to Koha, and are still trying to manage all the details around this. Circulation rules are a big thing we have to tackle here. At the moment, we have multiple libraries, and within each library we have both open and closed stacks as well as multiple other segmentations, all specified as shelving locations (authorized value LOC). These locations are not always governed by the same set of rules, so it would be very helpful if the system could support LOC as a circulation rule condition alongside library, patron category and item type. >From doing a fairly brief look at the code, it seems GetIssuingRule and GetLoanLength in C4/Circulation.pm are the main points where the ruleset is retreived. There will of course be all the places calling these two functions, as well as database management parts to consider. If we were to develop some sort of extension to these rules, what would be an appropriate approach? It should certainly be an option to turn on to be used, but should we consider LOC as a starting point, or should LOC just be one many possible choices in the configuration? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[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