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

[Bug 28474] New: Pass process_message_queue.pl params to before_send_messages plugin hooks
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '23

26 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28474 Bug ID: 28474 Summary: Pass process_message_queue.pl params to before_send_messages plugin hooks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be useful to send most of the process_message_queue.pl script parameters to any plugin before_send_messages hooks. For example, the Twilio Voice plugin uses before_send_messages to send phone messages, but if the script is called with "-t email", it doesn't know and will make phone calls! If that info were passed in, the plugin could be made aware of it and only make calls if no "-t" or a "-t phone" were set in the parameters. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 23059] New: reserves_stats.pl needs overhaul
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '23

26 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23059 Bug ID: 23059 Summary: reserves_stats.pl needs overhaul Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This bug is sort of a catch-all for changes that need to be made to the holds statistic wizard, reserves_stats.pl Two big issues: - By default, the wizard sets a value for items.homebranch and items.holdingbranch. That means it unexpectedly cuts out all bib-level holds and gives no clear indication that it's done so. You *can* change home and holding branch to not limit, but it's not intuitive. - The wizard splits holds into 5 statuses (Placed, Processed, Pending, Satisfied, and Cancelled) that aren't used anywhere else in Koha. These statuses aren't explained without diving into the code and don't match how we otherwise divide and talk about holds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 28205] New: Less important hold trapped before or no hold trapped in some cases (race condition)
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '23

25 Oct '23

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 2

[Bug 27873] New: Make display of patron restrictions, charges, notes, etc. consistent for check out and patron details screens
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '23

25 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27873 Bug ID: 27873 Summary: Make display of patron restrictions, charges, notes, etc. consistent for check out and patron details screens Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com On the check out screen (circulation.pl) info about the patron’s account displays in the following order: expiration, restrictions, charges, notes, messages. But on the patron details screen (moremember.pl) the info displays in a different order: charges, messages, notes, restrictions, expiration. For consistency it seems like the info should display in the same order on both screens. Additionally it would help when training new staff members and when working a busy information desk to be able to rely on finding the information in the same place on both screens. Our Library prefers the sort order that displays on the check out screen because it puts the expiration date, restrictions and then charges at the top of the screen so that staff can quickly see the status of the account and handle them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 25299] New: Date not showing on Details page when patron is going to expire
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '23

25 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25299 Bug ID: 25299 Summary: Date not showing on Details page when patron is going to expire Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The date doesn't show on the Details page when the patron is going to expire. It does appear on the "Check out" page, however. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 17228] New: Make two versions of SIPconfig.xml identical
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '23

23 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17228 Bug ID: 17228 Summary: Make two versions of SIPconfig.xml identical Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Packaging Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net We have two versions of SIPconfig.xml: etc/SIPconfig.xml debian/templates/SIPconfig.xml The former has been updated with some changes to the possible configuration of SIP2 servers, e.g. by bug 15006. The latter has not been updated with the same information. Since debian/templates/SIPconfig.xml contains no special placeholders or variables, this bug proposes to simply copy etc/SIPconfig.xml to debian/templates/SIPconfig.xml, so that admins using the packages will see an up-to-date SIP2 config example when they have enabled SIP2 for a site. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 28676] New: AutoCreateAuthorities can repeatedly generate authority records when using Default linker and heading is cached
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '23

21 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28676 Bug ID: 28676 Summary: AutoCreateAuthorities can repeatedly generate authority records when using Default linker and heading is cached Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 25189 avoided creating a new auth if the match_count was greater than 1, however, when we cache auth results we don't cache match_count, so if the same heading is searched, we will create a new record again: C4/Linker/Default.pm 38 if ( $self->{'cache'}->{$search_form.$auth_type}->{'cached'} ) { 39 $authid = $self->{'cache'}->{$search_form.$auth_type}->{'authid'}; 40 $fuzzy = $self->{'cache'}->{$search_form.$auth_type}->{'fuzzy'}; 41 } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 27379] New: Autocomplete addresses for a patron using Google Places API (Maps).
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '23

20 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27379 Bug ID: 27379 Summary: Autocomplete addresses for a patron using Google Places API (Maps). Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: ivan.dziuba(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 115043 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=115043&action=e… Google suggests addresses We are starting fill an address for a patron, Google suggests addresses which are related with patron's address. When you select a suitable address, the corresponding fields are filled automatically. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 18094] New: Patron search filters are broken by searchable attributes
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '23

20 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18094 Bug ID: 18094 Summary: Patron search filters are broken by searchable attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using searchable patron attributes they seem to be added to all searches as a contain To recreate: Add a new patron attrbute and mark it searchable Populate a new patron with 'potato' in that field Add/edit another patron to have email potato(a)invalidemail.com' Perform a patron search with filters 'Email' and 'Starts with' and query 'potato' You will see both patrons in your results Remove the potato email Perform search again You will be directed to the patron containing the potato attribute -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 25023] New: Claims Returned uses US date format (mm/dd/yyyy) in the Claims tab when UK date format (dd/mm/yyyy) is selected
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '23

20 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25023 Bug ID: 25023 Summary: Claims Returned uses US date format (mm/dd/yyyy) in the Claims tab when UK date format (dd/mm/yyyy) is selected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To replicate: 1. Turn on the Claims Returned feature by setting ClaimReturnedLostValue to 1 2. Change Koha's date format to UK format by setting DateFormat to dd/mm/yyyy 3. Check an item out to a patron 4. Note that the dates in the Check out screen are in UK format - dd/mm/yyyy 5. Claim the item as returned 6. Note that in the Claims tab, the date for 'Created on' is in US format mm/dd/yyyy 7. In the Claims tab, use the Actions button to mark the item as resolved. 8. Note that the 'Updated on' and 'Resolution' columns both show the date in US format - mm/dd/yyyy 9. Reload the Check out page for the patron and note that the 'Return claims' column correctly shows the date in UK format - dd/mm/yyyy -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25