September 2022 - Koha-bugs - lists.koha-community.org

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

02 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 28205] New: Less important hold trapped before or no hold trapped in some cases (race condition)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28205 Bug ID: 28205 Summary: Less important hold trapped before or no hold trapped in some cases (race condition) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com So our libraries ran into a strange hold problem which turned out to be a race condition: if you change priority of holds and return an item and build_holds_queue.pl cron is not yet run again the priority is not updated and you fill hold with less importance! After build_holds_queue.pl the priorities are OK because hold_fill_targets gets updated according to the right hold priority. Similar race condition also happens when you have already some items for the biblio in hold_fill_targets and add a new item to the biblio and try to return it it doesn't attach to any waiting holds until the build_holds_queue.pl is ran. To better understand the issue I think it is easier to look the code in C4::Reserves::_Findgroupreserve(). Explaining with words is bit difficult... Basically in that function the SQL selects > my $title_level_target_query = qq{ > my $query = qq{ should be UNION'ed to fix the case when adding new item which could potentially fill the hold. This might cause unoptimal logistic route to be used but still would follow the hold priority. To fix the issue of changing hold priorities we need to update hold_fill_targets table by calling C4::HoldsQueue::CreateQueue() every time staff member updates hold priorities in a biblio. But even with these improvements wouldn't this be buggy when deleting items from the biblio record? Not sure how to solve that case. Added major bug priority for this but if you feel like it doesn't deserve it feel free to change to normal. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[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 21781] New: message_transport_type should allow fallbacks
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21781 Bug ID: 21781 Summary: message_transport_type should allow fallbacks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Bug 21241 adds the ability for a fallback from email to sms when a patron email address isn't found on the suggestions notices. This shouldn't be limited to suggestions, but be a more comprehensive piece of work to capture other hard coded message transports. opac/svc/checkout_notes opac/opac-issue-note.pl opac/opac-memberentry.pl opac/opac-shareshelf.pl circ/pendingreserves.pl circ/article-request-slip.pl C4/Reserves.pm C4/Acquisition.pm misc/cronjobs/automatic_renewals.pl misc/cronjobs/membership_expiry.pl misc/cronjobs/stockrotation.pl Koha/ArticleRequests.pm Koha/Patron/Password/Recovery.pm Koha/Account.pm All of the above have a message_transport_type hard coded to some degree.. some may be better served left as is.. but many would benefit from a fallback. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

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

02 Nov '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 4

[Bug 24655] New: RoundFinesAtPayment can leave partial cent credits on patrons account
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24655 Bug ID: 24655 Summary: RoundFinesAtPayment can leave partial cent credits on patrons account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Create a manual invoice for 1.4286 for a patron 2 - Enable RoundFinesAtPayment 3 - Pay 1.43 on the patrons account 4 - The fine is paid off, however, if you view the accountlines in the DB the patron has a credit of .0014 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 27054] New: Round fines at charging
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27054 Bug ID: 27054 Summary: Round fines at charging Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We currently have the option to round fines at payment. However, there are still places where Koha can charge partial cent fines. We should give the option to round fines at charging. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 20153] New: Add new column "source" in the authorities pages's result
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20153 Bug ID: 20153 Summary: Add new column "source" in the authorities pages's result Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl hi, It would be nice if we could add a new column in the results page of a search in authority's module.In this new column we could se the subfield 040 $a who show the Organization that performed the original cataloging. With this new column with this new column titled "source", like the column in the z39.50 search, we would not need to go back to the authority record to see if it's a locally created authority or if it's imported. Patrick. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 25386] New: Internal server error when duplicate/too long barcodes are used in acquisition
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25386 Bug ID: 25386 Summary: Internal server error when duplicate/too long barcodes are used in acquisition 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 creating items on order or on receive there is a duplicate check for barcodes that usually detects if you are trying to reuse an already used barcode and prevents you from saving. But if you have used a barcode too long before and are not running with 'strict', the barcode will have been cut off at 20 characters. Now trying to create the next item with a too long barcode, where the 20 first characters match, will not trigger the duplicate warning, but instead an internal server error. The bad part is that the order will still be created/received, but the items are not. To test: - Edit an item in your catalog to have a barcode with 20 characters - Create a new basket in acq with either "create items on order" or "on receive" - Start the ordering process, when you get to the create items step - Enter your 20 character barcode, try to safe - Verify the duplicate message is triggered on saving - Add some characters to the end of your barcode - Verify on saving there is an internal server error - The order is created, but there are no new items -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 21266] New: Missing doc-head-close and cssinclude in sco-main.tt
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21266 Bug ID: 21266 Summary: Missing doc-head-close and cssinclude in sco-main.tt 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Custom stylesheet themes set in the OpacAdditionalStylesheet are not applied to the sco-main.tt page because this page is missing the following lines of code in the header: doc-head-close cssinclude -- You are receiving this mail because: You are watching all bug changes.

1 49