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

[Bug 30897] New: Gracefully reload Koha after plugin install/upgrade
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30897 Bug ID: 30897 Summary: Gracefully reload Koha after plugin install/upgrade 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org When a plugin is installed/upgraded, it would be good to send a SIGHUP to the Starman master, so that Koha will gracefully restart itself. As Kyle noted on the listserv, it is especially useful for plugins that add API routes, since the API can't use those until Starman workers are restarted. By doing a graceful restart, no active HTTP requests are interrupted. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 30887] New: Gravestone page for deleted authorities or biblios
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30887 Bug ID: 30887 Summary: Gravestone page for deleted authorities or biblios Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org When you assign a persistent identifier to your Koha record (auth or biblio) and you delete that record at some point in time, it would be good to resolve the persistent identifier to a gravestone/tombstone page that at least tells that the record has been deleted, perhaps even more. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 23609] New: Tie patron gender to an authorized value
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '24

13 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23609 Bug ID: 23609 Summary: Tie patron gender to an authorized value Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the interest of allowing greater flexibility, it'd be great to have gender tied to an authorized value so libraries can edit/add/delete options. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 32424] New: Allow guarantor to manage guarantee's holds
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '24

12 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32424 Bug ID: 32424 Summary: Allow guarantor to manage guarantee's holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org >From bug 3591 We already have the possibility to show checkouts and fines to the guarantor. It would be great if we could also have the possibility for guarantors to manage their guarantee's holds. - View holds - Suspend holds - Resume suspended holds - Cancel holds (I think that's all we can do with holds?) Like the checkouts and fines, this should be turned on in the guarantee's account. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 34062] New: Additional contents with library set do not appair in OPAC
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '24

12 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34062 Bug ID: 34062 Summary: Additional contents with library set do not appair in OPAC 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When we create an additional content and specify the library, we are not able to see the additional contents in the OPAC, the OPAC_BRANCH_DEFAULT is used only once, if we reload the page we can't see the additional contents anymore. To reproduce Add « SetENv OPAC_BRANCH_DEFAULT 'CPL' » in the koha-httpd.conf and restart or reload apache 1- Connect to the staff interface 2- Go to Tools->Pages 3- Click on New entry 4- Fill the following field Display location -> OPAC, library -> Centerville, Publication date -> today date, fill the title and the content 5- Save the form 6- get the created page id (select max(idnew) from additional_contents;) 7- Visit http://master/cgi-bin/koha/opac-page.pl?page_id=X (where X is the created page id) in a private tab --> the page is displayed well 8- refresh the page --> the page is no more displayed you get the message «This page does not exist.» -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 29443] New: Expired patrons should not be allowed to place ILL request on OPAC
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '24

12 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29443 Bug ID: 29443 Summary: Expired patrons should not be allowed to place ILL request on OPAC Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: dch(a)interleaf.ie Expired patrons should not be allowed to place ILL request on OPAC. The SysPref BlockExpiredPatronOPACActions should be checked and if it is set to 'Block' the patron should be blocked from placing ILL request as well as the other OPAC actions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 32900] New: Curbside pickups - "Please fill in this field" tip is untranslatable
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32900 Bug ID: 32900 Summary: Curbside pickups - "Please fill in this field" tip is untranslatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N 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: frederic(a)tamil.fr When scheduling a pickup, there is a tip when you hover the cursor on the date field that says "Please fill in this field". I could not find this string anywhere in the .po files, even after an update. To get this string: 1. Enable the CurbsidePickup system preference 2. Set up curbside pickup for a library (e.g. Centerville) 2.1. Go to Administration > Curbside pickup 2.2. Click the tab for the library 2.3. Fill out the form: - Enable: Check - Pickup interval: 10 (or other) - Maximum patrons per interval: 3 (or other) - Patron-scheduled pickup: leave unchecked - Enable for waiting holds only: leave unchecked 2.4. Enter a couple of time periods (e.g. - Day: Sunday - From: 10:00 - To: 12:00 2.5. Click 'Add' 2.6. Click 'Save configuration' 3. Schedule a pickup, hover over the date field 3.1. Go to Circulation > Curbside pickups 3.2. Click 'Schedule pickup' 3.3. Search for a patron name (e.g. Henry) 3.4. Hover the cursor on the date field --> The tip says "Please fill in this field." To translate : cd misc/translator ./translate update xx-XX git grep "Please fill in this field" --> No result -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 25621] New: Some tests in t/DateUtils.t fail when timezone is not UTC
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25621 Bug ID: 25621 Summary: Some tests in t/DateUtils.t fail when timezone is not UTC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Test Suite Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org To reproduce: 1. Verify that TZ environment variable is not defined 2. Verify that $KOHA_CONF does not contain <timezone> 3. Run `date` to verify that you have a local time different than UTC 4. prove t/DateUtils.t Expected output: % prove t/DateUtils.t t/DateUtils.t .. 1/76 # Failed test 'dt_from_string handles seconds with 1 decimal place' # at t/DateUtils.t line 130. # got: '1325447940' # expected: '1325462340' # Failed test 'dt_from_string handles seconds with 2 decimal places' # at t/DateUtils.t line 133. # got: '1325447940' # expected: '1325462340' # Failed test 'dt_from_string handles seconds with 3 decimal places' # at t/DateUtils.t line 136. # got: '1325447999' # expected: '1325462399' # Failed test 'dt_from_string handles seconds with 3 decimal places and a timezone' # at t/DateUtils.t line 139. # got: '1325447999' # expected: '1325462399' # Looks like you failed 4 tests of 76. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 30540] New: Double processing invalid dates can lead to ISE
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30540 Bug ID: 30540 Summary: Double processing invalid dates can lead to ISE 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org In the KohaDates filter we process our passed date using dt_from_string before passing it to output_pref. dt_from_string handles bad dates in an eval block, falling back to assigning a floating timezone. However, in the subsequent call to output_pref we try to set the timezone a second time and this time it is not in an eval and so will throw an internal server error for such dates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 21559] New: Rules for automatic framework codes
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21559 Bug ID: 21559 Summary: Rules for automatic framework codes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Allow setting rules in a system preference, what framework code should be automatically set for biblio, based on the MARC record fields. Does not affect anything if the MarcToFrameworkcodeAutoconvert system preference rules aren't used. The "Default" framework is always overridden, if the rules match, but some other framework chosen by you is always used. Explanation of the rule format: ------------------------------- The syspref is YAML, with a specific format: - <field> <value>: <frameworkcode> If the <field> in the record contains <value>, the <frameworkcode> is used for the record. <field> is one of: "xxx" (field xxx in the MARC record) "xxx/yy" (field xxx, character location yy) "xxx/yy-zz" (field xxx, character locations yy-zz) "xxx$v" (field xxx, subfield v) Fields can be combined with plus-sign, then the field values have plus-sign between them. The field-rules are checked in order from top to bottom, and the first rule with a matching value is used. If the (sub)field has been repeated in the MARC record, only the first matching (sub)field is checked. If none of the rules match, the framework code is not changed. Example: - 008/35-37 + 000/06: fin+a: BKSFIN - 000/06: a: BKS c: MU e: MP This would make record with 000/06 = "a" AND 008/35-37 = "fin" use the BKSFIN framework, and any other record with 000/06 = "a" use BKS, 000/06 = "c" would be MU, and 000/06 = "e" would give MP -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22