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

[Bug 31832] New: Add reference for EnableItemGroups to EnableItemGroupHolds system preference
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '23

26 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31832 Bug ID: 31832 Summary: Add reference for EnableItemGroups to EnableItemGroupHolds system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: System Administration 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 Item group holds only make sense if the library allows item groups in the first place. We should add a note to the system preference linking them together. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 34831] New: Add input types "tel", "email" and "url" to vendor edit form
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '23

26 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34831 Bug ID: 34831 Summary: Add input types "tel", "email" and "url" to vendor edit form Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Replacing the generic input type attribute "text" can improve browsers' handling of the fields, for instance "validation parameters and relevant keyboard in supporting browsers and devices with dynamic keyboards." https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 34281] New: Transfer limits have no impact on CanBookBeRenewed
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '23

26 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34281 Bug ID: 34281 Summary: Transfer limits have no impact on CanBookBeRenewed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Circulation Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, a book on a separate branch can't be renewed if there's a hold on a different branch even if the is a transfer limit that forbids all transfers between those two branches, this is an obvious oversight, as our customers have branches that function as completely separate libraries. Items on one branch should not be dependent on other branches when there is no option for transfer. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 34547] New: Add transfer reason to returns.pl table
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '23

26 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34547 Bug ID: 34547 Summary: Add transfer reason to returns.pl table Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice for the reason for branch transfers (branchtransfers.reason) to be a configurable column on returns.pl, so libraries know which checkins may need more attention in the case of a dismissed modal or receipt printing issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 33947] New: Move GetAllIssues to Koha
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '23

26 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33947 Bug ID: 33947 Summary: Move GetAllIssues to Koha Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 33576] New: Records are not indexed when imported if using Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '23

25 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33576 Bug ID: 33576 Summary: Records are not indexed when imported if using Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The importing is done in a transaction. We call the indexer form inside the transaction. This means that when rabbit sends the task, it may not be found in the DB yet. We need to ensure we index after the transaction completes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 34822] New: BatchUpdateBiblioHoldsQueue should be called once per import batch when using RealTimeHoldsQueue
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '23

25 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34822 Bug ID: 34822 Summary: BatchUpdateBiblioHoldsQueue should be called once per import batch when using RealTimeHoldsQueue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 33019] New: Records not indexed in Elasticsearch ES when first catalogued
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '23

25 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33019 Bug ID: 33019 Summary: Records not indexed in Elasticsearch ES when first catalogued Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz We have a Koha instance where records are not being indexed into Elasticsearch when they are first catalogued. They can be accessed if you go to the catalogue detail page directly, but cannot be searched. However if you edit the record and save, it is indexed successfully. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[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 34666] New: _Findgroupreserve is not returning title level matches from the queue for holds with no item group
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '23

25 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34666 Bug ID: 34666 Summary: _Findgroupreserve is not returning title level matches from the queue for holds with no item group 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The check in _Findgroupreserve is eliminating matches with NULL group id's -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37