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

[Bug 27901] New: cancelling acq order does not delete item record, causes error
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '22

17 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27901 Bug ID: 27901 Summary: cancelling acq order does not delete item record, causes error Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Prior to 20.05 when an order was cancelled from the basket, the item created when the order was placed was deleted also. In 20.05, users now get the message: An error has occurred. The order has been cancelled, although one or more items could not have been deleted. To recreate: 1. Add biblio and item to basket 2. Cancel the order and delete the biblio 3. Get the error message 4. Verify that the Holdings table still shows the item, but the acq correctly shows the cancellation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 32015] New: Cannot search for basket creator in advanced order search
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '22

17 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32015 Bug ID: 32015 Summary: Cannot search for basket creator in advanced order search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org Since Bug 30578 the previous auto completion (circ/ysearch.pl) was replaced with the jQuery autocomplete functionality. The search on the advanced order search page in acquisitions still sends "term" as query parameter, but it is now received by api/v1/patrons instead of circ/ysearch.pl and that api route does not recognise this parameter name. I do not understand how the two autocomplete features work, or what has to be done to fix this, so I'm unable to provide a patch for it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32113] New: Missing table from batchMod.pl when coming from a bib record
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '22

17 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32113 Bug ID: 32113 Summary: Missing table from batchMod.pl when coming from a bib record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org There are several ways to access batch item modification, one of them is from a bibliographic record. Normally, there is a table showing item details at the top of the page. But that table is missing when we access the page from a bibliographic record. To test: 1) Go to Reports 2) Make a report of item numbers (e.g. select itemnumber from items limit 5) 3) Click Batch operations with X visible records 4) Choose Batch item modification --> Note that there is a table of items at the top of the page 5) Go to a bibliographic record that has at least one item (and less than 1000) 6) Click Edit > Edit items in batch --> Note that there is no table at the top of the page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 31892] New: Regression: return to /manage-marc-import.pl after importing batch
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '22

17 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31892 Bug ID: 31892 Summary: Regression: return to /manage-marc-import.pl after importing batch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 31748 Now that MARC batch importing uses the background job system, after one imports a staged MARC batch one needs to follow a link over to the completed background job and then another link back to manage-marc-import.pl for the batch you've just imported. Previously, importing a batch simply re-loaded manage-marc-import.pl in order to show the imported bibs. We should either restore this exact behavior or at least make sure that the completed process bar page contains a link directly to the imported batch. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31748 [Bug 31748] Restore progress bar on record import -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31543] New: MaxComponentRecords link is broken
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31543 Bug ID: 31543 Summary: MaxComponentRecords link is broken 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I was trying out the Component records feature and noticed the link when you have more component records than MaxComponentRecords is broken. I'm using Elasticsearch, if that changes anything. 1)Import the example file 1.1) Go to Tools > Stage MARC records for import 1.2) Upload the example file 1.3) In the form, choose the format 'MARCXML' 1.4) Click 'Stage for import' 1.5) Click 'Manage staged records' 1.6) Click 'Import this batch into the catalog' 2) Change MaxComponentRecords to 10 3) In the staff interface, search the catalog for 'easy piano' 4) Click on the record 'Easy piano pieces for children' 5) Click on the 'show all component parts' link at the bottom of the Components tab --> it searches for HASH(...) - returns no results 6) Try the same in OPAC --> it searches for HASH(...) - returns no results -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 30730] New: Holds to Pull should not list items with a notforloan status
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30730 Bug ID: 30730 Summary: Holds to Pull should not list items with a notforloan status Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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, nick(a)bywatersolutions.com The holds to pull list (pendingreserves.pl) is mistakenly showing titles where there are no available items and telling staff to pull items with negative notforloan statuses that should keep them off the list. To recreate: - have a bib with 2 items, both holdable. Give one of these items a notforloan status with a negative value (like Ordered in the testing docker data). - place a title-level hold on your bib - confirm your bib is showing on Holds to Pull as expected, prompting staff to pull the item that does not have a not for loan status (correct!) - take the item that does not have a not for loan status and check it out to a different patron, make sure not to fill or cancel your hold - reload Holds to Pull, see your title is still listed and now Koha is directing staff to the item with a notforloan status In building this list, we start by getting only the bibs that have at least one holdable item, but then we neglect to actually exclude the non-circulating items from the final output. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 30935] New: Holds to pull shows wrong first patron
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30935 Bug ID: 30935 Summary: Holds to pull shows wrong first patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 I've seen a couple of bugs on this and they're all 'Resolved' but I still see the problem. Maybe it's not the exact same thing... So I'm creating this in case. Someone else can test and tell me if I'm crazy or not. When a biblio has more than one hold (record-level), the 'First patron' column on the 'Holds to pull' report is not showing the actual first patron, but the last in the line. I tried it on a bywater sandbox, just in case it was my installation that was the problem, and it does the same thing. To test : 1) Place a record-level hold on a biblio with an available item 2) Check the Holds to pull page (circ/pendingreserves.pl) --> The biblio should appear in the list and the patron should appear in the 'First patron' column 3) Place a second record-level hold on the same biblio 4) Go back to the Holds to pull page --> The biblio is still there, but the patron in the 'First patron' column is the second patron 5) Place a third record-level hold on the same biblio 6) Go back to the Holds to pull page --> The biblio is still there, but the patron in the 'First patron' column is the third patron Other bugs I found that talk about this: Bug 24488 (Closed fixed), Bug 30337 (pushed to master) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 32231] New: Improve display of items, when items are created from staged files
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32231 Bug ID: 32231 Summary: Improve display of items, when items are created from staged files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 32046 With the improved display from bug 32046 and the test plan from bug 32166 we see the items created from staged files: https://snipboard.io/DLZQ41.jpg They could look a little prettier. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32046 [Bug 32046] When adding a new records from a staged files, there are style issues -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 32193] New: Reindent item details template
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32193 Bug ID: 32193 Summary: Reindent item details template Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/catalogue/moredetail.pl?biblionumber=X OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 32042 I propose to reformat the item details template in the staff interface (moredetail.tt) so that it has consistent spacing and indentation. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32042 [Bug 32042] Add page-section to items tab (cat) -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 32147] New: Capitalization: E-Ressource management should be E-ressource management
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32147 Bug ID: 32147 Summary: Capitalization: E-Ressource management should be E-ressource management 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 This is according to our capitalization rules. -- You are receiving this mail because: You are watching all bug changes.

1 27