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

[Bug 31568] New: Renaming/removing an authorised value does not cascade to linked tables
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '22

17 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31568 Bug ID: 31568 Summary: Renaming/removing an authorised value does not cascade to linked tables Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We could give lots of examples here. E.g. location is controlled by category LOC having a value like CHILD. If you rename it to CHILDREN, your items still contain the old value. This cannot be solved with a FK since an authorised value may be in use under several AV categories. Maybe there are cases where you do not want to have an AV immediately cascade the change in a linked table? Also note that we have a maintenance script looking for these inconsistencies (bug 21466), but if we could reduce the volume here, I wouldnt mind. How should we best address this need? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 20200] New: Show MARC 770 Supplement/Special Issue Entry on detail pages
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '22

17 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20200 Bug ID: 20200 Summary: Show MARC 770 Supplement/Special Issue Entry on detail pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently 770 is not shown in Koha on the detail pages. We should add the display of this field. Examples: 770 08 _iAnfangs darin, später selbst. _aGesellschaft für Verbreitung von Volksbildung _tJahresbericht der Gesellschaft für Verbreitung von Volksbildung _dBerlin, 1872 _w015234347 770 08 _iBeil. ab 1902 _aDie Volks-Bibliothek _dBerlin, 1896 _w014944286 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[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 16 Nov '22

16 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 31892] New: Regression: return to /manage-marc-import.pl after importing batch
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 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 26835] New: Ability to remove Lost Items from Patrons Account without Checking in
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '22

16 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26835 Bug ID: 26835 Summary: Ability to remove Lost Items from Patrons Account without Checking in 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Libraries all have unique ways of handling lost statuses. At the moment, Koha allows libraries to remove a lost item from the patron's account when set to a lost status and also to not remove it. Great! However, we would like to see Koha go one step forward after the library chooses to not remove the lost item from the patron's account, to allow for the item to be removed at a later date. A preference would be to have the Batch Item Modification allow for libraries to change an item's lost status to another lost status, and also remove it from the patron's account. Using the batch item modification will allow for libraries to do this operation in bulk ! Currently, if a library has the option to credit the patron if they do return a lost item, the library has no way of telling Koha (at check-in) don't refund, don't remove the lost status, just remove it from the patron's account. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 31525] New: Street number not being accessed correctly on patron search results page
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '22

15 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31525 Bug ID: 31525 Summary: Street number not being accessed correctly on patron search results page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you use the streetnumber field in the patron form, this doesn't show with the address in patron search results. To reproduce: 1) Edit a patron's contact information 2) Under Main Address put an address, make sure to put something in the Street number field 3) Do a simple patron search that will yield results (i.e. "a") 4) Confirm the street number does not show, but the rest of the address does -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12