April 2021 - Koha-bugs - lists.koha-community.org

[Bug 27738] New: Fix fallback for unset DefaultCountryField008 system preference
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27738 Bug ID: 27738 Summary: Fix fallback for unset DefaultCountryField008 system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 13912 Bug 13912 added DefaultCountryField008 to allow defaulting the place of publication to something other than the previous default of xxu ("somewhere in the United States, but I don't know what state"). Trying to follow the Koha Way of never changing existing behavior, only adding a preference to fix it, it intended to fall back to xxu, but https://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=cataloguing/valu… thought the preference would be undefined if it wasn't set, and then a QA followup updated the DB to add it so it's always defined, and the // "xxu" is unreached and the default value of the pref, '', gets space-padded to three characters long, ' '. Since we've now gone 3.3 years with the default having switched from the unfortunate choice of 'xxu' to the invalid ' ' without anyone filing a bug about it, I assert that the Koha Way is wrong in this case, that nobody actually wanted to retain the behavior of defaulting to saying that every book was published in an unknown US state (or if they did exist, they already fixed it by using that as their DefaultCountryField008), and we can fix the bug of defaulting to an invalid value by choosing a new default when DefaultCountryField008 isn't set, the value "|||" which is "no attempt to code" which is precisely the case when the cataloger doesn't change it and the system adminstrator doesn't say it should have a particular value whether or not that value is correct. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13912 [Bug 13912] Add syspref for default place of publication (country code) for field 008, range 15-17 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 27936] New: AllowItemsOnHoldCheckoutSIP does not allow checkout of items currently waiting for a hold
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27936 Bug ID: 27936 Summary: AllowItemsOnHoldCheckoutSIP does not allow checkout of items currently waiting for a hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: kyle(a)bywatersolutions.com Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The syspref text says "[Allow/Don't allow] checkouts of items reserved to someone else via SIP checkout messages. If allowed do not generate RESERVE_WAITING and RESERVED warning. This allows self checkouts for those items. If using the holds queue items with pending holds will be marked as "unavailable" if this set to "Don't allow"." However, setting the syspref to Allow *only* allows sets sip to ignore the RESERVED warning. Items that are currently waiting for hold pickup will still generate a RESERVE_WAITING message and block the checkout. Either the description or the behavior needs to change to make this accurate. In contrast, AllowItemsOnHoldCheckoutSCO also says "If allowed do not generate RESERVE_WAITING and RESERVED warning" and, for the SCO, this is accurate. With AllowItemsOnHoldCheckoutSCO set to allow, items waiting for another patron's hold can be checked out without a warning at the SCO. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 28132] New: Remove "this" from button descriptions on basket summary page
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28132 Bug ID: 28132 Summary: Remove "this" from button descriptions on basket summary page Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org As it makes for unnecessary long translations and is not consistent with our labelling on other pages, I suggest to make the following changes to the buttons on the acq basket summary: * Delete this basket => Delete basket * Close this basket => Close basket Note: Close basket will only show, when the basket is not marked as standing order and at least one order line has been added. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 26459] New: Allow sip_cli_emulator to handle cancelling holds
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26459 Bug ID: 26459 Summary: Allow sip_cli_emulator to handle cancelling holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 28046] New: Add "Additional fields" link on acquisition navigation menu
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28046 Bug ID: 28046 Summary: Add "Additional fields" link on acquisition navigation menu Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I think if we have a link to add additional fields in the serials module as added back by bug 28006, we should also have one on the acquisitions page. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 28006] New: Restore "Additional fields" on navigation menu
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28006 Bug ID: 28006 Summary: Restore "Additional fields" on navigation menu Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org In previous versions of Koha (at least 18.05) was displayed a link "Add subscription fields" on the navigation side bar. It has dispared in Master, probaby because of creation of the "Additional fields" menu, but it was a useful link for users with the 'manage_additionnal_fields' permission. It could be great to add it on the Acquisitions module too. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 27748] New: Encoding problem in link to OverDrive results
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27748 Bug ID: 27748 Summary: Encoding problem in link to OverDrive results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org If you have OverDrive enabled and do a search in the OPAC, you get a link that says e.g. "Found 1 results in the library's OverDrive collection". But if you search contains non-ASCII characters, the search goes wrong. Example: Do a search for "göteborg": https://kohaopac.alingsas.se/cgi-bin/koha/opac-search.pl?q=g%C3%B6teborg (The URL shows the query as q=göteborg, but when I paste it here it is turned into q=g%C3%B6teborg.) The link says: Found 4 results in the library's OverDrive collection The actual link is: https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=g%F6te… If you foloow that link you get to this page: https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=g%F6te… which says "OverDrive search for 'g�teborg'" and shows 53 results, because the query was cut off at the "ö", and a search was actually made for just the letter "g" (whatever comes before the first non-ascii-char). If I change the encoding in the link from: https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=g%F6te… to: https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=g%C3%B… or https://kohaopac.alingsas.se/cgi-bin/koha/opac-overdrive-search.pl?q=götebo… the page shows 4 results, as promised. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 24000] New: working title
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '21

25 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24000 Bug ID: 24000 Summary: working title 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 27940] New: KohaAdminEmailAddress is missing from OpacMaintenance page
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '21

24 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27940 Bug ID: 27940 Summary: KohaAdminEmailAddress is missing from OpacMaintenance page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org To reproduce: KohaAdminEmailAddress = Some valid email address OpacMaintenance = Show OPAC/cgi-bin/koha/maintenance.pl shows this text: Koha online catalog is offline for system maintenance. We'll be back soon! If you have any questions, please contact the site administrator. "site administrator" is a link, but it only links to "mailto:", the actual email address from KohaAdminEmailAddress is missing. I think the problem is here: <p>The [% IF ( LibraryNameTitle ) %][% LibraryNameTitle | html %][% ELSE %]Koha online[% END %] catalog is offline for system maintenance. We'll be back soon! If you have any questions, please contact the <a href="mailto:[% KohaAdminEmailAddress | uri %]">site administrator</a></p> Specifically, [% KohaAdminEmailAddress | uri %] does not actually get the value from KohaAdminEmailAddress. Patch coming! -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 28074] New: Browse controls in staff details are sometimes weird
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '21

24 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28074 Bug ID: 28074 Summary: Browse controls in staff details are sometimes weird Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The browse control feature doesn't work quite right in the OPAC detail. 1. If you do a search with 3-4 results, go to the record and use the browse controls, when you get to the last record if you attempt to go to the 'next' you'll end up on a page which says 'record not found'. 2. Do a search with exactly 10 results. Click on the first record, the 'next' arrow is not a link, you cannot move to the next result. This is because in js/browser.js, if you look at the current_search Object and specifically at current_search.offset you will see that current_search.offset is a string. We try to do calculations with that variable and JavaScript performs string concatenation instead of addtion. For example: current_search.offset + me.curPos == current_search.total When the offset is '1' and we add it to 0, the result is 10. Therefore if the offset is the first and the total is 10, it thinks we are on the last result (10) and doesn't let use move forward. Converting current_search.offset to an integer solves the problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14