February 2020 - Koha-bugs - lists.koha-community.org

[Bug 16912] New: Koha:: Patrons - Move AddEnrolmentFeeIfNeeded to add_enrolment_fee_if_needed
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '23

01 Aug '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16912 Bug ID: 16912 Summary: Koha::Patrons - Move AddEnrolmentFeeIfNeeded to add_enrolment_fee_if_needed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 20212] New: Slowness in Receiving in Acquisitions
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '23

28 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20212 Bug ID: 20212 Summary: Slowness in Receiving in Acquisitions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jesse(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Convert order tables from pre-loading all order data to ajax tables that load order data on an as needed basis. -- You are receiving this mail because: You are watching all bug changes.

1 347

[Bug 19361] New: Linking an authorised value category to a field in a framework can lose data
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '23

28 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19361 Bug ID: 19361 Summary: Linking an authorised value category to a field in a framework can lose data Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you link an authorised value to a framework after you have done data entry on the same field, editing the record with the new authorised value drop down, and not filling it in will lose the data in the field. To reproduce: choose a free entry MARC field and add a record with some data in that field. create an authorised value category and link it to that field in a framework edit your record with the authorised value link now defined, do not select an authorised value from the field, and save it note that the data for that field is now gone. I have only heard this reported on 16.05, but it very well may be in Master. It would pay to check. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 17787] New: Suppressed items seems so still be included in number of search results
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '23

28 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17787 Bug ID: 17787 Summary: Suppressed items seems so still be included in number of search results 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: viktor.sarge(a)regionhalland.se QA Contact: testopia(a)bugs.koha-community.org We have a use case where like 99% of the collection is hidden and only a few selected items are displayed in the opac (by showing their covers up front on the main page). When going to the detail page and clicking the link for an author that has a long list of records (but only one visible in the opac) I might get indication of 63 hits in the search results and a the links to pages 1,2,3 etc for search results. Only problem is that there is actually only one result since the rest are suppressed. My guess is that the code calculating the number of hits and creating links to the pages of search results is not talking to the suppression system. I could not find any open bugs about this. Perhaps because our use of suppression is a bit of a edge case(?) I ended up "solving" the problem by removing the links on author etc. since we don't use search anyhow. I'll likely not research the issue further, but I felt I should at least report it and keep an eye out. All input is welcome. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 19192] New: Update default DUEDGST and PREDUEDGST notices
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '23

26 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19192 Bug ID: 19192 Summary: Update default DUEDGST and PREDUEDGST notices 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The current default digest notices are DUEDGST You have <<count>> items due PREDUEDGST You have <<count>> items due soon These are not terribly useful defaults -- the whole reason for having digest notices is to display item detail for items which are due or coming due. I suggest the following instead: DUEDGST Dear <<borrowers.firstname>> <<borrowers.surname>>, You have <<count>> items due: <<items.content>> PREDUEDGST Dear <<borrowers.firstname>> <<borrowers.surname>>, You have <<count>> items due soon: <<items.content>> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 20454] New: Suspend Holds if patron wouldn't be able to check items out
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20454 Bug ID: 20454 Summary: Suspend Holds if patron wouldn't be able to check items out 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: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a person can't check out an item due to hitting the fine limit, it would be great if the holds could be suspended automatically so it wasn't filled until the account was cleared off. This would be a good system preference so systems that didn't want to use it wouldn't be forced into it. Currently in our system patrons can't check out if they have more than $5 in fines. Sometimes they place a hold, rack up fines, and can't check out the book when it comes in for them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18855] New: Fines cronjob can cause duplicate fines if run during active circulation
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '23

18 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Bug ID: 18855 Summary: Fines cronjob can cause duplicate fines if run during active circulation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On systems with a decent amount of fines it seems the fines cron can cause issues for patrons. The problem seems to be: 1 - Fines job runs and selects overdues 2 - Patron with an overdue returns books, fine is updated, item is checked in 3 - Fines job iterates to the item that was checked in during step 2, sees there is no accruing fine, generates a new accruing fine I am not sure what the best solution here is, possibly we should confirm the issue before generating the fine in the cronjob? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60

[Bug 23775] New: Claiming a serial issue doesn't create the next one
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '23

18 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23775 Bug ID: 23775 Summary: Claiming a serial issue doesn't create the next one Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com == test plan == 1. have a vendor with an email address for claiming late issues 2. have a subscription linked to this vendor - You can create a new one with arbitrary values 3. Go to "Serial collection" 4. click "Edit serials" 5. Status of the latest: change from Expected to Claimed 6. save 7. see that the next issue has been created 8. go to /cgi-bin/koha/serials/claims.pl 9. make a claim on the expected issue of the previously used serial 10. Then you see that the next issue hasn't been created -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 24517] New: Zebra: date-entered-on-file misses 6th position
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '23

18 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24517 Bug ID: 24517 Summary: Zebra: date-entered-on-file misses 6th position Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Date entered on file is in MARC21 tag 008 position 00 to 05 (or 1-6 for normal humans). In Koha only the first 5 digits are indexed with Zebra. Does not really facilitate searching ;) <index_control_field tag="008" offset="0" length="5"> <target_index>date-entered-on-file:n</target_index> </index_control_field> <index_control_field tag="008" offset="0" length="5"> <target_index>date-entered-on-file:s</target_index> </index_control_field> <xslo:template match="marc:controlfield[@tag='008']"> <z:index name="date-entered-on-file:n"> <xslo:value-of select="substring(., 1, 5)"/> </z:index> <z:index name="date-entered-on-file:s"> <xslo:value-of select="substring(., 1, 5)"/> </z:index> Elasticsearch appears to do a better job: date-entered-on-file: label: date-entered-on-file mappings: - facet: '' marc_field: '008_/0-5' marc_type: marc21 sort: ~ suggestible: '' - facet: '' marc_field: '008_/0-5' marc_type: normarc sort: ~ suggestible: '' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 22820] New: Display 830 series information when there is no 490 tag (MARC21)
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '23

15 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 Bug ID: 22820 Summary: Display 830 series information when there is no 490 tag (MARC21) 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: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Currently, the 830 tag will display only when the 490 tag is present and indicator 1=1. It is possible to have a valid 830 tag without a corresponding 490 tag. We need to include logic in the stylesheet to display the 830 when no 490 is found. -- You are receiving this mail because: You are watching all bug changes.

1 22