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

[Bug 26490] New: Column configuration for account-fines hides the wrong columns
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26490 Bug ID: 26490 Summary: Column configuration for account-fines hides the wrong columns 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hello! I was trying to find out how to hide the "Home library" column from the transactions table in the patron's account (Patron account > Accounting tab > Transactions tab). The right column id in Table settings is account-fines (Administration > Table settings > Patrons > account-fines). There are two problems here: 1) The home library column doesn't appear in the table settings for account-fines 2) Checking the notes column in the account-fines table settings hides the home library column This means that because there are columns missing, the other ones are off. To replicate on master: 1) Go to a patron's account 2) Click on the Accounting tab and then the Transactions tab 3) In another browser tab, go to Administration > Table settings > Patrons 4) In the account-fines table, check the box to hide the Notes column 5) Go back to the patron's account and refresh the page. Notice the Notes column is still there but the Home library column is not there anymore I think Home library is the only missing column. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 26438] New: Follow up to bug 23463 - return from Koha::Item overwrites existing variable
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26438 Bug ID: 26438 Summary: Follow up to bug 23463 - return from Koha::Item overwrites existing variable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The added calls to Koha::Item use a temporary variable called $item to store their return this hides the existing variable $item which is the lineitem being processed. Calling lineitem methods on it causes an error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 26451] New: Small typo in bulkmarcimport.pl
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26451 Bug ID: 26451 Summary: Small typo in bulkmarcimport.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz misc/migration_tools/bulkmarcimport.pl displays a small typo whenever a MARC modification template is being used: "modofication" instead of the correct "modification". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 26464] New: Code correction in opac-main when news_id passed
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26464 Bug ID: 26464 Summary: Code correction in opac-main when news_id passed 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 Theoretical change. If somehow the search would return more than one result, the code is wrong. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 26435] New: AutoSelfCheckID syspref description should warn it blocks OPAC access
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26435 Bug ID: 26435 Summary: AutoSelfCheckID syspref description should warn it blocks OPAC access Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client 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 The OPAC blocks login of the account specified in the AutoSelfCheckID syspref (even if the AutoSelfCheckAllowed syspref is off and the account in question doesn't have self_check permissions). The descriptive text on the syspref should warn of this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 21259] New: Add search filters to staged imports
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21259 Bug ID: 21259 Summary: Add search filters to staged imports Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org We can sort on the whole table, but sometimes you are just looking for a specific record in a bigger batch. A search option would be really nice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 17849] New: Show only unpaid fees/fines in OPAC
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17849 Bug ID: 17849 Summary: Show only unpaid fees/fines in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently all payments, credits, paid and unpaid fine entries are shown in the OPAC. It would be less confusing, if we only showed unpaid fines and credits. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 26466] New: Zebra finds results in empty instance
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26466 Bug ID: 26466 Summary: Zebra finds results in empty instance Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: anke.bruns(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org Koha still finds results for bib records even though all bib records have been deleted from the instance. Zebra index has been rebuilt with option -f after deleting, so I would expect no search results at all. The search results lead to empty records anyway, but they shouldn't be there at all. What else has to be deleted exept items, deleteditems, biblioitems, deletedbiblioitems, biblio, deletedbiblio, biblio_metadata, deletedbibliometadata so that Zebra won't find anything after rebuilding? Is there another way to empty a Koha instance of its bib records apart from TRUNCATE-ing the tables mentioned above in the database? Thanks! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 26491] New: With Elastisticsearch search results in staff show always only 1 item even if record has multiple
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26491 Bug ID: 26491 Summary: With Elastisticsearch search results in staff show always only 1 item even if record has multiple Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de This is kind of a strange thing I just noticed while looking for a record with multiple items: With Elasticsearch active, the result list always says: 1 item... for all records. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26105] New: Incorrect hold status shown if hold is ignored after transfer to pickup location
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26105 Bug ID: 26105 Summary: Incorrect hold status shown if hold is ignored after transfer to pickup location Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com To recreate: - Have an item at Branch A - Place a hold for pickup at Branch B - Check the item in at Branch A, confirm hold and transfer - Confirm request.pl and detail.pl for your bib show item is in transit to Branch B - Confirm circulation.pl and moremember.pl for your patron show item is in transit to Branch B - Check item in at Branch B, click Ignore on the hold popup - Detail.pl shows "There is an item level hold on this item (priority = 0)." -- the expected message for an item with an item-level hold with no Found value - Request.pl shows priority of "In transit" and message of "Item waiting at Branch B since" with no waiting date - Circulation.pl and moremember.pl show no priority or status for this hold - the database shows found=T for this hold To be honest, it's hard to think of a good reason why a library would ignore a hold at the end of its transfer, but this is still confusing and worth addressing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5