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

[Bug 31285] New: Regression: item.datelastseen does not update on duplicating item
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31285 Bug ID: 31285 Summary: Regression: item.datelastseen does not update on duplicating item Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Previous to 21.11, when you would duplicate an item record, the date last seen would be automatically updated. This no longer happens - the date last seen is retained from the original item. To replicate: >From a bib record with an item attached, select Edit - Edit items >From the actions tab, select duplicate Update the date accessioned and click save >From the Normal tab, note that the new item has an updated date accessioned, but the date last seen has not been updated. This behavior is now different from when adding a new item - when a new item is added, the date last seen is automatically set to the current date. This is the expected behavior when adding an item. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 6419] Add customizable areas to intranet home pages
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6419 --- Comment #12 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- The solution suggested here is to have 1 syspref per page. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 6419] Add customizable areas to intranet home pages
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6419 Jonathan Druart <jonathan.druart+koha(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart+koha@gmail. | |com --- Comment #11 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- It would have been nice to provide something generic and flexible. We could have offered a way to add additional content to any pages in Koha. With an editor, a list of pages, then we can inject the content to the correct body. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 30673] New: Improve is_valid_date function for validating date strings
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30673 Bug ID: 30673 Summary: Improve is_valid_date function for validating date strings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The is_valid_date() function in calendar.js has two jobs: Confirm that the date string matches the current date format according to a regular expression; and confirm that the date is an actual date. Both must be true. For example: "2002-03-14" matches the date format "Y-m-d" and is a valid date -- valid date. "03/14/2002" doesn't match the date format "Y-m-d" even though it is a valid date -- invalid date. "38-44-2103" doesn't match the date format "Y-m-d" and isn't a valid date -- invalid date. is_valid_date() needs some changes in order for it to correctly handle custom date formats being specified which override the default date format (from the system preference). It also needs a new way to check that a date string represents a valid date. The old jQueryUI method looks similar but behaves differently. $.datepicker.parseDate() would throw an exception if the date were invalid. flatpickr.parseDate() will try to interpret an invalid date as if it were valid. For example: flatpickr.parseDate("2002-48-66", "Y-m-d") -> Date Sat Feb 04 2006 00:00:00 flatpickr.parseDate("2002-48-66", "m/d/Y") -> Date Mon Aug 02 2027 00:00:00 -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 30836] New: Elasticsearch mappings.yaml is out of sync with upgraded databases
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30836 Bug ID: 30836 Summary: Elasticsearch mappings.yaml is out of sync with upgraded databases Change sponsored?: --- Product: Koha Version: unspecified 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We discovered on IRC today that the mappings.yaml default mappings for ES indexing has fallen out of sync with upgraded databases.. We need to create a DB update for each mappings change and we haven't been doing so. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 31324] New: Use patron search when editing the borrowernumber of an ILL request
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31324 Bug ID: 31324 Summary: Use patron search when editing the borrowernumber of an ILL request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de Depends on: 22321 With bug 22321 it's possible to change the borrowernumber an ILL request is attached to, but it requires to enter the borrowernumber. We should provide a proper way to edit this information, using a standard patron search and showing the name of the patron. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22321 [Bug 22321] Make it possible to edit illrequests.borrowernumber -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 9717] Local use recorded for holds/transfers
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9717 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #19 from David Cook <dcook(a)prosentient.com.au> --- I just bumped into this for the first time, and I really didn't expect this bug to be such a saga... After reviewing the code in C4/Circulation.pm, the patch could theoretically be small, but it looks like no one can agree on what should or should not constitute a local use. But the thing is... if it's not recorded as "localuse", it's actually going to be recorded as a "return" anyway, so perhaps it's a much of a muchness. If people do care enough, I suppose we could have a multiple value system preference like RecordLocalUseExceptions which defines a list of situations where "return" is logged instead of "localuse". For example, you might want to record "return" instead of "localuse" if it's "OnHold" or "HasTransfer" (although this could be split into several different ones... since you can have outbound and inbound tranfers). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #455 from David Cook <dcook(a)prosentient.com.au> --- Another thing I haven't checked here is how it works with hold limits... that's a bit of a rabbithole as well... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|31303 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31303 [Bug 31303] Fatal error when viewing OPAC user account with waiting holds -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 09 Aug '22

09 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #454 from David Cook <dcook(a)prosentient.com.au> --- Created attachment 138869 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=138869&action=e… Bug 15516: [QA followup] Only show hold groups for multi hold in staff interface -- You are receiving this mail because: You are watching all bug changes.

1 0