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

[Bug 30992] New: Hard to translate single word strings
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30992 Bug ID: 30992 Summary: Hard to translate single word strings Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr There are a few single word strings that are hard to translate without context. Maybe we could use i18n with context hint to make this a little easier: koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-serial-issues.tt:124 for koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-reserve.tt:448 at Actually the latter highlights a case, where the spans might have a negative effect as they break the sentence apart into small bits: https://git.koha-community.org/Koha-community/Koha/src/branch/22.05.x/koha-… It's something like: [Waiting|On hold] for patron X [at|expected at] X [since X] The main problem here is, that these small bits can translate differently (at least in German) depending on context. In general it's quite bad to build up sentences like this as you don't know if the English grammar will fit any other languages. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 14783] Allow patrons to change pickup location for non-waiting holds
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14783 --- Comment #41 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 141730 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=141730&action=e… Bug 14783: (QA follow-up) Add unit tests. This commit adds unit tests for Bug 14783. Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14783] Allow patrons to change pickup location for non-waiting holds
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14783 --- Comment #40 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 141729 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=141729&action=e… Bug 14783: (QA follow-up) Change "Pick up location" to "Pickup location" in table. Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14783] Allow patrons to change pickup location for non-waiting holds
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14783 --- Comment #39 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 141728 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=141728&action=e… Bug 14783: (follow-up) Move pickup library form into modal This patch attemps to simplify the list of holds by moving the form for changing a hold's pickup library into a modal dialog. This patch also makes minor tweaks to the CSS for the "X" close button shown in modal in windows. Instances where modal markup used "x" have been updated to use the Bootstrap 4 standard "×" To test, apply the patch and rebuild the OPAC SCSS (https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staf…) - Turn on the OPACAllowUserToChangeBranch system preference. - Log in to the OPAC as a user with holds. - In the view of your holds, confirm that each hold which can be modified shows a "Change" link. - Clicking the link should show a modal window with the title of the item on hold shown in the header. - Confirm that changing the pickup location works correctly. Signed-off-by: Barbara Johnson <barbara.johnson(a)bedfordtx.gov> Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14783] Allow patrons to change pickup location for non-waiting holds
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14783 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #141499|0 |1 is obsolete| | Attachment #141500|0 |1 is obsolete| | Attachment #141501|0 |1 is obsolete| | Attachment #141502|0 |1 is obsolete| | --- Comment #38 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 141727 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=141727&action=e… Bug 14783: Change pickup location from opac. This patch allows users to change the pickup location for their holds from the opac. A syspref (OPACAllowUserToChangeBranch) controls at what stage a hold can be changed. To test: 1. Set up holds with diffrent statuses for a patron (pending, waiting, in transit, suspended) 2. No pickup locations for any hold should be able to be changed. 3. Turn on and off the different options under OPACAllowUserToChangeBranch. Make sure that only the corresponding holds can be changed from the opac. Check eg in the staff client that pickup location has changed. 4. The available pickup locations should respect any transfer restrictions. (Same as the holds list for a biblio in staff client) 5. For an in-transit hold: Check in the item at the original pickup location. 6. Note that it will be redirected to the new location. Sponsored-by: Lunds Universitetsbibliotek Signed-off-by: Owen Leonard <oleonard(a)myacpl.org> Signed-off-by: Barbara Johnson <barbara.johnson(a)bedfordtx.gov> Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14783] Allow patrons to change pickup location for non-waiting holds
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14783 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31668] New: Avoid displaying nothing in facet
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31668 Bug ID: 31668 Summary: Avoid displaying nothing in facet Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Adding a way to avoid displaying nothing in facet for opac and client staff when using elasticsearch as SearchEngine. Test plan: 1) Do a search, like 'a' 2) Look in the bottom of the sidebar on the left and see that there is an empty language -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 31269] New: DataTables error when managing staged MARC records
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31269 Bug ID: 31269 Summary: DataTables error when managing staged MARC records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 31138 made some DataTable errors much more visible, which is good. One that was noticed was when managing staged MARC files. To recreate: 1. Stage a MARC record for import 2. Once you have one click on 'Manage staged records' 3. You will see an alert that says "Something went wrong when loading the table." 4. If you dismiss that you should see the following error: DataTables warning: table id=records-table - Requested unknown parameter '' for row 0, column 4. For more information about this error, please see http://datatables.net/tn/4 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 27463] New: OAI-PMH date handling in ListBase.pm
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27463 Bug ID: 27463 Summary: OAI-PMH date handling in ListBase.pm Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: rudolfbyker(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently in Koha/OAI/Server/ListBase.pm two different criteria are used for querying dates and displaying dates. When displaying the "Last Modified" date, this is used: SELECT MAX(timestamp) FROM ( SELECT timestamp FROM biblio_metadata WHERE biblionumber = ? UNION SELECT timestamp FROM deleteditems WHERE biblionumber = ? UNION SELECT timestamp FROM items WHERE biblionumber = ? ) bi But when querying, only biblio_metadata.timestamp is used. This should be made consistent. We could use a query like this (using a join, but removing the need to do a separate query for each record, so it might actually be faster than what we have now): select bm.biblionumber, greatest(bm.timestamp, i.timestamp) as t from biblio_metadata bm inner join items i on bm.biblionumber=i.biblionumber having t >= '2020-07-14' and t <= '2020-07-15' limit 10; Furthermore, we should only use items.timestamp and deleteditems.timestamp when the user has the "include_items" option set in their OAI-PMH config. It does not make sense to query item timestamps if you are only sending data about the records, and not the items. Therefore, if "include_items" is disabled, we can do a simpler query: select biblionumber, timestamp from biblio_metadata where timestamp >= '2020-07-14' and timestamp <= '2020-07-15' limit 10; See full discussion on IRC: http://irc.koha-community.org/koha/2021-01-18#i_2324076 Definition of "datestamp" for reference: https://www.openarchives.org/OAI/openarchivesprotocol.html#Datestamp -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 19064] New: OAI-PMH Records appearing in OAI that can' t be found in OPAC
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19064 Bug ID: 19064 Summary: OAI-PMH Records appearing in OAI that can't be found in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: marrone.patricio(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hello, While harvesting Koha records from the OAI-PMH interface, I found a series of records that can't be accessed using the OPAC interface. That is, the harvester finds a record with an identifier, say http://example.com/cgi-bin/koha/oai.pl?verb=GetRecord&metadataPrefix=oai_dc… that shows the complete record. Trying to link to the OPAC using the biblionumber in the last part of the identifier, say http://example.com/cgi-bin/koha/opac-detail.pl?biblionumber=572 I get a 404 error. I have yet to confirm this, but this might be related to the records being hidden in the OPAC view being leaked into OAI. In that case, I would expect the record to have a deleted status in OAI so that in can be removed from the harvesting results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2