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

[Bug 33616] New: JavaScript error in when using claims return button in checkout table
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33616 Bug ID: 33616 Summary: JavaScript error in when using claims return button in checkout table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Set ClaimReturnedLostValue to a LOST value 2. Check out an item to a patron. 3. Click the Claim returned button within the checkout table. 4. Get spinning icon in place of the button 5. In the web developer tools console: Uncaught TypeError: value.match is not a function Looks like this is coming from includes/js-date-format.inc: 46 if ( ! value.match(/^\d{4}-\d{2}-\d{2}$/ ) ) { 47 m = m.tz(tz); 48 } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 31818] New: Advanced editor doesn't show keyboard shortcuts
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31818 Bug ID: 31818 Summary: Advanced editor doesn't show keyboard shortcuts 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When using the advanced cataloguing editor, the modal showing the defined keyboard shortcuts no longer works. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 32804] New: Importing and replacing items causes inconsistency when itemnumber match and biblio match disagree
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Bug ID: 32804 Summary: Importing and replacing items causes inconsistency when itemnumber match and biblio match disagree Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When 'Item processing' option during import is set to 'replace' itemnumber matches do not check any other data - so the item's biblionumber is set to the matched biblionumber, but the biblioitemnumber is not updated or checked This means that if you import a record containing an item with an itemnumber from another record you will end up with an item with mismatched biblio and biblioitem numbers This happens in consortia when multiple libraries have ordered the same biblio. Two biblios are created, later the final import with barcodes etc. is imported to replace items, and the more full bib is chosen for the biblio match, so items are half moved. To recreate: 1 - Be using the sample data in koha testing docker 2 - Stage the sample file on this report 3 - Match on KohaBiblio(999$c) / Item processing: replace 4 - Note the biblio match is "The complete novels / Austen, Jane" 5 - View the staged marc, note the barcode 39999000004090 in an item 6 - Search for that barcode 7 - You find biblio "Five novels : complete and unabridged / Gustave Flaubert" 8 - Import the file 9 - Check the db: SELECT * FROM items WHERE biblionumber != biblioitemnumber; 10 - Note the mismatch -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #235 from Nick Clemens <nick(a)bywatersolutions.com> --- (In reply to Aleisha Amohia from comment #234) > There are lots of signoffs on these patches, can this be marked Passed QA? Hi Aleisha, It appears I was wrong in comment 187, see comment 222 It is a question of how the fallback should work, so we either need a DB update, or to change the expectation for when a rule is not set -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 --- Comment #11 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Marcel de Rooy from comment #10) > (In reply to David Cook from comment #9) > > (In reply to Katrin Fischer from comment #7) > > > Marked bug 32385 as a dependency for this one. I think in order to have > > > different timeouts, we need different sessions first. > > > > Actually, thinking about this again, you would already have different > > sessions between the OPAC and staff interface, so long as your hostname is > > different, which should be 99% of Koha instances... > > How do you calculate that 99% ? Perhaps I should say 99% of commercially supported Koha instances. Even then you're right that it's a total guess based off the idea that Koha defaults to separate hostname for OPAC and staff interface when using Debian packages, and most commercial support vendors for Koha seem to use Debian packages. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 --- Comment #10 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to David Cook from comment #9) > (In reply to Katrin Fischer from comment #7) > > Marked bug 32385 as a dependency for this one. I think in order to have > > different timeouts, we need different sessions first. > > Actually, thinking about this again, you would already have different > sessions between the OPAC and staff interface, so long as your hostname is > different, which should be 99% of Koha instances... How do you calculate that 99% ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 --- Comment #9 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #7) > Marked bug 32385 as a dependency for this one. I think in order to have > different timeouts, we need different sessions first. Actually, thinking about this again, you would already have different sessions between the OPAC and staff interface, so long as your hostname is different, which should be 99% of Koha instances... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '23

28 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #234 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- There are lots of signoffs on these patches, can this be marked Passed QA? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33632] New: Editing a list with multiple pages always returns to first page
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33632 Bug ID: 33632 Summary: Editing a list with multiple pages always returns to first page Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When removing items from page 3 of a 10 page list, the user is always returned to page 1 of the list once the browser refreshes the page. The user than has to navigate back to the page of the list they were working on to continuing to work. This is time consuming when working on large lists. To reproduce: 1. Create a list with enough items to have multiple pages. 2. Navigate to page 3 of the list. 3. Select a few items and remove them from the list. The user is then returned to page 1 of the list. It would be nice if the user was returned to the page they were on, which would be page 3 of this example and not page 1. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 31740] New: Illrequests table has a foreign key constraint on status_alias
by bugzilla-daemon＠bugs.koha-community.org 27 Apr '23

27 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31740 Bug ID: 31740 Summary: Illrequests table has a foreign key constraint on status_alias Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I am not sure the intent of this foreign key, however it seems problematic as we can't tie it to a single category To test: 1 - Add an authorised value for Asort1: Authorised value: MONKEY Description: Capuchin 2 - Add an authroised value for LOC: Authorised value: MONKEY Description: Spider 3 - Put an illrequest in the DB: INSERT INTO illrequests (branchcode,status,status_alias) VALUES ('CPL','REQUEST_TEST','MONKEY') 4 - Delete one of the authorised values above 5 - Check the DB: SELECT status_alias FROM illrequests WHERE status = 'REQUEST_TEST' 6 - Note the status is nulled by deletion of unrelated authroised value -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4