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

[Bug 20885] New: Transferring an item on hold results in bypassing restrictions, actually doing the transfer and can be piled up if repeated
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '20

26 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20885 Bug ID: 20885 Summary: Transferring an item on hold results in bypassing restrictions, actually doing the transfer and can be piled up if repeated 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: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The first name was «Transferring an item on hold results in chaos» Disclaimer: I'm not sure if what I did makes sense from a functional point of view. == Test plan == 1. Add transfer restrictions staff:/cgi-bin/koha/admin/branch_transfer_limits.pl For all item types => clear all 2. Place a hold on a record 3. go to the transfer page staff:/cgi-bin/koha/circ/branchtransfers.pl 4. Try to transfer the item 5. You should see the message «Transfer is not allowed for [...]» OR retry with another site to fall into your restrictions 6. But you also see the "Transferred items" table showing the transfer This is a bug. The transfer shouldn't have been scheduled. 7. On the same page: redo a transfer 8. You should see "Item is already at destination library." This is a bug. This is even worst. The transfer shouldn't have been actually done! 9. But wait there is more, the transfer has been add to the table. This is a bug. It's still scheduled anyway. A transfer to the same branch! 10. Redo it again and it will pile up! 11. Raise your hands and ask loudly: Why! Tried on master the 24 of April and on version 16.11.15 To ensure that bug 19530 hadn't an influence on this. Might be related to bug 20344 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 27087] New: Allow encoding level comparison on record import
by bugzilla-daemon＠bugs.koha-community.org 23 Dec '20

23 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27087 Bug ID: 27087 Summary: Allow encoding level comparison on record import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The MARC leader position 17 stores a record's encoding level -- # indicates a fully encoded and verified record, with numbers 1-8 indicating increasingly un-encoded and un-verified status. It would be useful to create the option on batch import of only overlaying if the incoming record has a lower (better) encoding level than the existing record. I could see this as either a new option in the "Action if matching record found:" dropdown when staging for import OR as a new variety of match check in the matching rule. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 26792] New: Create simple is_authenticated and is_authorized methods for AuthN/AuthZ
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '20

22 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26792 Bug ID: 26792 Summary: Create simple is_authenticated and is_authorized methods for AuthN/AuthZ Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org There should be simple methods for checking if a web user is authenticated and authorized. Basically, you check a cookie value for a session ID, check if that session ID maps to an authentic user account, and then check if that user account has authorizations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 21287] New: Report Zebra search errors to web server logs and staff client
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '20

21 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21287 Bug ID: 21287 Summary: Report Zebra search errors to web server logs and staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au At the moment, there's no way of knowing that a Zebra query failed unless you go into the Zebra server logs and have a certain level of verbosity for those logs. I'm proposing that we catch Zebra search errors and report them to the web server logs and surface them on the staff client. We can probably keep the OPAC the way it is as we probably don't want OPAC users seeing errors, but it could be good for staff to see, so that they can tell administrators and administrators can tell developers, and then we can fix all the things! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20150] New: Acquisitions wizard always uses listprice
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '20

21 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20150 Bug ID: 20150 Summary: Acquisitions wizard always uses listprice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When using the acquisitions wizard, you can choose between different options: - Amount: - Ordered amount: - Spent amount: The calculations are always done with listprice. Especially for the amount spent this makes the wizard not match up with the amounts on the acquisition homepage as the actual amount spent can be quite different from the list price used when ordering. I think it probably should be calculated like this: - Amount: list price of ordered items + actual price of received items - Ordered amount: list price - Spent amount: actual price -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 27073] New: refactor cover image to get image(s) (url) from api call/template include
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '20

21 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27073 Bug ID: 27073 Summary: refactor cover image to get image(s) (url) from api call/template include Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: koha(a)trust-box.at QA Contact: testopia(a)bugs.koha-community.org it seems for me that there is (template) code duplication to show cover images. see grep -rl OPACAmazonCoverImages includes/shelfbrowser.inc includes/opac-bottom.inc modules/opac-user.tt modules/opac-opensearch.tt modules/opac-results-grouped.tt modules/opac-readingrecord.tt modules/opac-detail.tt modules/opac-shelves.tt modules/opac-showreviews-rss.tt modules/opac-showreviews.tt modules/opac-results.tt I'm not sure if this is autogenerated? maybe this duplicate code should be wrapped in an api call, with more logic implemented than in the rather crude template if-statments -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 18789] New: Send a Koha::Patron object to the templates
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '20

21 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18789 Bug ID: 18789 Summary: Send a Koha::Patron object to the templates Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 18403 The simplify and make uniform the code, the controller scripts should send a Koha::Patron object to the templates and not all attributes of a patron. That will make the code much more easier to maintain and will be less error-prone. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18403 [Bug 18403] Hide patron information if not part of the logged in user library group -- You are receiving this mail because: You are watching all bug changes.

1 112

[Bug 26131] New: console errors when attempting to open SCO related system preferences
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '20

18 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26131 Bug ID: 26131 Summary: console errors when attempting to open SCO related system preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When you search for SCO related system preferences you will get a console error: Uncaught Error: Syntax error, unrecognized expression: #collapse_Self_check-in_module_(sci-main.pl) This makes it impossible to open/edit the system preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 26548] New: [20.05] Update for 20.05.03.001 has wrong SQL
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '20

18 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26548 Bug ID: 26548 Summary: [20.05] Update for 20.05.03.001 has wrong SQL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) 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 22386 $DBversion = '20.05.03.001'; 22387 if( CheckVersion( $DBversion ) ) { 22388 $dbh->do(q{ 22389 INSERT IGNORE INTO systempreferences ( `variable`, `value`, `options`, `explanation`, `type` ) VALUES 22390 ('DefaultLongOverdueSkipLostStatuses', '', NULL, 'Skip these lost statuses by default in longoverdue.pl', 'Free'), 22391 }); 22392 22393 NewVersion( $DBversion, 25958, "Allow LongOverdue cron to exclude specified lost values"); 22394 } -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 26785] New: JS errors in pos/pay.tt in 20.05.x
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '20

18 Dec '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26785 Bug ID: 26785 Summary: JS errors in pos/pay.tt in 20.05.x Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In 20.05 there is a JS error in pos/pay.tt. This error does not exist in master. TO recreate: 1. enable EnablePointOfSale 2. enable UseCashRegisters 3. Go to /cgi-bin/koha/pos/pay.pl 4. See the console error Not 100% sure but maybe this is fixed in master because of Bug 26234? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16