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

[Bug 19288] New: Holds placed on a specific item after a next available hold will show varied results
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '20

21 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288 Bug ID: 19288 Summary: Holds placed on a specific item after a next available hold will show varied results Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests 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(a)bywatersolutions.com, nick(a)bywatersolutions.com When a hold is placed on an item as "next available" and then a hold is placed on same item, but it is placed on a specific copy, Koha will show the specific copy hold on the status screen of the item incorrectly and sometimes give the hold to that specific copy before next available. On 16.11.07 Steps: 1. Place a "next available" hold on an item with only one copy. 2. Place a "specific item" hold this same record. 3. Looking at the holds- they are in the correct order 4. Look at the status of the item in the holdings table you can see that the hold for the "specific copy" is next- not the next available. 5. Check this item in and see which hold gets filled first. 6. Results vary on the process of who gets the hold when checking in this item . Sometimes the specific item will get filled before the hold that was placed as next available even though the "Next available" hold was placed first. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 17687] New: Rename column subscriptionhistory.recievedlist to receivedlist
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17687 Bug ID: 17687 Summary: Rename column subscriptionhistory.recievedlist to receivedlist Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 18498] New: Staff can place next available holds when rule is set to forced
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18498 Bug ID: 18498 Summary: Staff can place next available holds when rule is set to forced 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com While the item level holds is set to force in the rule, and it is enforced on the OPAC, staff can still place next available holds on these items. To test: 1) Set a rule for an item with the Item Level Holds set to Force. 2) Try to place a hold on an item governed by this rule in the OPAC. See that you can only place on an item specific hold. 3) Try to place a hold on an item governed by this rule in the staff client. See that you CAN place a next available hold on the item. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 16780] New: Specify due date always sets time as AM when using 12 hour time format
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16780 Bug ID: 16780 Summary: Specify due date always sets time as AM when using 12 hour time format 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: nick(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 - On the checkout screen for a patron specify a due date and a PM time 2 - Checkout an item 3 - Note the due date for the item and the time in the box have switched to AM -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 19189] New: Reserving and renewing item in OPAC selenium test
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19189 Bug ID: 19189 Summary: Reserving and renewing item in OPAC selenium test Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This Selenium test will start with a biblio being cataloged using a z39.50 target, then items are added. Then the OPAC reserve functionality is tested by loading the OPAC and placing a hold on the item. Then the item is checked out to the user in the intranet, and the OPAC renew functionality is tested by loading the OPAC and renewing the item -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 19184] New: Purchase workflow selenium test
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19184 Bug ID: 19184 Summary: Purchase workflow selenium test Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This Selenium test will go through the whole purchase workflow including adding a purchase suggestion in the OPAC (using the Z39.50server), accepting the suggestion in the intranet, creation of a vendor and basket and then adding the suggested item to the basket. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 19183] New: Acquisition module setup selenium test
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19183 Bug ID: 19183 Summary: Acquisition module setup selenium test Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This selenium test will go through the initial process of setting up the Acquisition module including creating a currency, budget and fund -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 19182] New: Item search in intranet and OPAC selenium test
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19182 Bug ID: 19182 Summary: Item search in intranet and OPAC selenium test Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This selenium test will create a new biblio and add items to that biblio and then the item search functionality in the intranet and OPAC will be used to try to find the added biblio in the catalogue -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 23383] New: IdRef link appears even with syspref is off
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23383 Bug ID: 23383 Summary: IdRef link appears even with syspref is off Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org IdRef link is displayed via XSLT. There is a test of syspref with just if value is defined. But in installer/data/mysql/sysprefs.sql you see this pref will be 0 by default, which is true in XPATH. We should test that pref is 1. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 23411] New: SMS messages should not fall back to 'email'
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23411 Bug ID: 23411 Summary: SMS messages should not fall back to 'email' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 15967 ensured that an email notice that falls back to print when the patron has no email will send a print notice using the email template if there is no print template. When SMS and fallback were added this means that an SMS message where there is no SMS template will use the email template - it shouldn't as SMS messages need to be shorter, we should instead fail sending SMS if no SMS template defined -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20