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

[Bug 31872] New: Remove warning in cron-jobs section of the manual about needing StaticHoldsQueueWeight to use RandomizeHoldsQueueWeight
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '23

26 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31872 Bug ID: 31872 Summary: Remove warning in cron-jobs section of the manual about needing StaticHoldsQueueWeight to use RandomizeHoldsQueueWeight 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: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Cron jobs section of the manual (https://koha-community.org/manual/22.05/en/html/cron_jobs.html#circulation) still contains the warning: "Leaving StaticHoldsQueueWeight empty is contraindicated at this time. Doing so will cause the build_holds_queue script to ignore RandomizeHoldsQueueWeight, causing the script to request hold fulfillment not randomly, but by alphabetical order." This warning was removed from other sections of the manual in bug 22846 but seems to have survived here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29248] New: Manual 21.05 - 'position' missing in syspref UNIMARCAuthorityField100
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '23

26 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29248 Bug ID: 29248 Summary: Manual 21.05 - 'position' missing in syspref UNIMARCAuthorityField100 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: e.betemps(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hi, Translating syspref in this manual, I think some positions are missing Emplacements : ../../source/authoritiespreferences.rst:189 Asks: Use the following text for the contents of UNIMARC authority field 100 position ??? (fixed length data elements). have a nice day, Manu. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 31798] New: REST API: POST endpoint for Items
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '23

26 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31798 Bug ID: 31798 Summary: REST API: POST endpoint for Items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 26228] New: Update gulpfile to work with Node.js v12
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26228 Bug ID: 26228 Summary: Update gulpfile to work with Node.js v12 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Node.js v8 has gone EOL on december 2019. We need to shift the required version to v12, but we rely on old gulp and friends that need to be updated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 31442] New: Node.js v12 is EOL
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31442 Bug ID: 31442 Summary: Node.js v12 is EOL 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The currently maintained LTS release is v16. We could start using v18 which will be the new LTS in october and would be current until 2025. https://nodejs.org/en/about/releases/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29489] New: <<branches.branchname>> in RENEWAL notice subject field
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29489 Bug ID: 29489 Summary: <<branches.branchname>> in RENEWAL notice subject field Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org Using <<branches.branchname>> returns the library name when used in the subject field for a notice template with one apparent exception. If an item is renewed from the OPAC the RENEWAL notice is sent with the subject "<<branches.branchname>>" We are set up so that an item renewal via the OPAC should get recorded statistically as a renewal by the branch the item was checked out at. It would be nice if <<branches.branchname>> filled in the branch name of the library where the item was checked out rather than "branches.branchcode" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32993] New: Holds priority changed incorrectly with dropdown selector
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32993 Bug ID: 32993 Summary: Holds priority changed incorrectly with dropdown selector Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When one tries to change holds priority via dropdown selector, holds priority doesn't change correctly. To test: 1. Find record with at least 3 holds. 2. Change first holds priority as 2. => Priority is changed to 3. 3. Try to change priority back to 1. => Priority is changed to 2. Somewhat same as bug 19636 but not quite. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 32937] New: copyright symbol
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32937 Bug ID: 32937 Summary: copyright symbol Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: ashley.day(a)rcm.ac.uk QA Contact: testopia(a)bugs.koha-community.org Our library includes the copyright symbol when cataloguing the publication date (264$c) according to RDA 2.11.1.3. Searching dates as free text (not using the advanced date search) is an issue for us in both the opac and staff interface. Koha is not pulling all possible results because we are using the copyright symbol in the record. I've been advised that Koha treats ©2023 and 2023 as two different words. Of course when adding the copyright symbol to the date to the general search, the correct number of results are shown. We don't want to require a user to know alt codes to produce a copyright symbol, and many students simply are not going to use an advanced date search. Is it possible for KOHA to have the ability to ignore a copyright symbol in 264c for free text searching and return search results based on the date alone? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 28315] New: PopupMARCFieldDoc is defined twice in addbiblio.tt
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28315 Bug ID: 28315 Summary: PopupMARCFieldDoc is defined twice in addbiblio.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The `PopupMARCFieldDoc` JS function is defined twice in addbiblio.tt.. probably a merge error at some point.. should be easily resolved. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 32232] New: Koha crashes if dateofbirth is 1947-04-27, 1948-04-25, or 1949-04-24
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32232 Bug ID: 32232 Summary: Koha crashes if dateofbirth is 1947-04-27, 1948-04-25, or 1949-04-24 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I think this only happens if the server/computer is set to an Eastern Canadian timezone. In 1947, 1948 and 1949, Canada decided to switch to daylight saving time at midnight rather than the usual 2am. Therefore, 1947-04-27 00:00:00, 1948-04-25 00:00:00 and 1949-04-24 00:00:00 don't exist in this timezone. Even if borrowers.dateofbirth is set to 'date' (not 'datetime'), Koha crashes, saying the date doesn't exist. I suspect it would happen with any date, but dateofbirth is the most likely (only) field to have dates in those years. To test: 1. Create a patron, setting the date of birth to one of these three dates - 1947-04-27 - 1948-04-25 - 1949-04-24 2. Save the patron --> Error I tested this on production installations in 21.05 and it works fine. Production installations in 22.05, it crashes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24