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

[Bug 11573] Fine descriptions related to Rentals are untranslatable
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11573 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #91529|0 |1 is obsolete| | Attachment #91530|0 |1 is obsolete| | Attachment #91531|0 |1 is obsolete| | Attachment #91532|0 |1 is obsolete| | Attachment #91800|0 |1 is obsolete| | --- Comment #67 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 91801 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91801&action=ed… Bug 11573: Make rental accountlines translatable To test: 1. Set up an item type with a rental charge 2. Issue an item with that item type 3. Check fines, a charge of type 'Rent' will be visible with a description of 'Rental'. 4. Renew the item 5. Check fines, a charge of type 'Rent' will be visible with a description of 'Renewal of Rental Item TITLE BARCODE' where TITLE and BARCODE are the items title and barcode. 5. Apply the patch 6. Repeat steps 1-4, charge descriptions should now be empty and charge types should display 'Rental fee' and 'Renewal of rental item'. 7. Repeat steps 1-6 for an item type with a daily rental charge and note the charge types are now 'Daily rental fee' and 'Renewal of daily rental item' Signed-off-by: Martin Renvoize <martin.renvoize(a)ptfs-europe.com> Signed-off-by: Kyle M Hall <kyle(a)bywatersolutions.com> Signed-off-by: Nick Clemens <nick(a)bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11573] Fine descriptions related to Rentals are untranslatable
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11573 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23362] New: AlternateHoldingsField is displayed even if an item is created and checked out
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23362 Bug ID: 23362 Summary: AlternateHoldingsField is displayed even if an item is created and checked out Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Field set in AlternateHoldingsField displayed when an item is finally created and checked out. Test plan: - in AlternateHoldingsField, write 998a for exemple - create a biblio with 998a filled - 998a displayed on detail biblio in holding tab - 998a displayed on list result on availability field - finally create an item - do not clear field 998a - 998a is no longer displayed - check out item - on list result, 998a is displayed even if an item is exists Regards, Marjorie -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 11573] Fine descriptions related to Rentals are untranslatable
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11573 --- Comment #66 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 91800 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91800&action=ed… Bug 11573: (follow-up) Handle daily rental in db update -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 22473] New: Use koha-conf.xml modification time as cache key
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22473 Bug ID: 22473 Summary: Use koha-conf.xml modification time as cache key Change sponsored?: --- Product: Koha Version: unspecified 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: robin(a)kallisti.net.nz QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- >From this IRC conversation: <fridolin> rkrimme1: did you flush memcached ? <magnuse> can't hurt :-) <magnuse> and yeah, i think you have to, for changes to koha-conf.xml to be picked up if this is the case, when creating and accessing memcached for koha-conf values, the actual modification time of the koha-conf should be appended to the key values. This means that if the file is updated, the cache is automatically invalid. It requires running stat on each request, but as the koha-conf file isn't actually being opened and parsed, this will be very fast. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 12949] changing child to adult doesn't remove link to guarantor
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12949 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aleisha(a)catalyst.net.nz, | |hayleymapley(a)catalyst.net.n | |z --- Comment #11 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- I've rebased and reattached the second commit so it applies cleanly on master. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12949] changing child to adult doesn't remove link to guarantor
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12949 --- Comment #10 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 91790 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91790&action=ed… Bug 12949: (follow-up) Disable syspref by default Implemented fixes based on test feedback: * Renamed syspref now called: RemoveGuarantorDataFromGuaranteeWhenUpdatedToAdult * Also set syspref to 0 (disabled) by default * When syspref is enabled and a guarantee is updated to an 'Adult' their borrowers.guarantorid, borrowers.contactname, borrowers.contactfirstname, borrowers.relationship are reset to NULL. Updated test plan: 1. Create an adult patron (make sure to set a first and last name) and select 'Add child' and save the child record 2. Run the following database query, and notice there are values for guarantorid, contactname, contactfirstname, relationship: SELECT guarantorid, contactname, contactfirstname, relationship FROM borrowers WHERE borrowernumber=<childsborrowernumber>; 3. On the child record select More > Update child to adult patron. 4. Select a new adult patron category and save 5. Notice guarantor information is still displayed on the new adults record 6. Repeat step 2 and notice guarantorid is empty/NULL and contactname and contactfirstname, relationship are unchanged 7. Now create a child record with an unlinked guarantor: In the patron home page select 'New patron'. Note: Make sure the patron category you select is of category type 'Child' 8. In the guarantor area of the patron creation page input a firstname and surname and don't select 'Set to patron' and save/submit the page 9. Repeat step 2 making the borrowernumber you enter the borrowernumber of the patron you made in step 8 and notice guarantorid is empty and contactname and contactfirstname are not empty. i.e. our guarantor is not linked to a Koha patron 10. Notice guarantor information is shown on the patron summary page of our user 11. Repeat step 3,4,5 and notice guarantor information is still displayed 12. Apply patch 13. Navigate to installer/data/mysql directory Enter the Koha shell: sudo koha-shell <instancename> Run: ./updatedatabase.pl 14. In staff client visit Administration > Global System preferences and search for RemoveGuarantorDataFromGuaranteeWhenUpdatedToAdult syspref and confirm it is disabled 15. Repeat steps 1-5 and notice that the guarantor information is displayed on the new adult's record (i.e. when the RemoveGuarantorDataFromGuaranteeWhenUpdatedToAdult syspref is disabled the current Koha behaviour occurs). 16. In the database confirm the guarantorid is NULL and contactname, contactfirstname and relationship are not set to NULL. 17. Repeat steps 7-10 and notice that the guarantor information is displayed on the new adult's record Also repeat step 16 and confirm the same outcome 18. Set GuarantorsMustBeLinkedToPatronAccount syspref to enabled 19. Repeat steps 1-5 and confirm the guarantor information is not displayed on the new adult's record (i.e. setting GuarantorsMustBeLinkedToPatronAccount syspref to enabled implements the behaviour change). Also repeat step 16 and confirm the guarantorid, contactname, contactfirstname and relationship are all NULL 20. Repeat steps 7-10 and confirm the guarantor information is not displayed Also repeat step 16 and confirm the guarantorid, contactname, contactfirstname and relationship are NULL 21. Sign off Sponsored-By: Brimbank Library, Australia -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12949] changing child to adult doesn't remove link to guarantor
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12949 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #91726|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8643] Add important constraint to MARC tags and subfields
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8643 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA CC| |alexbuckley(a)catalyst.net.nz --- Comment #80 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Hi Maryse, Thank you for your contribution. Unfortunately when testing this I am not getting a confirmation message when I set 100 tag as 'Important' and try to submit the Edit item with all 100 tag subfields empty. Similarly, I am not getting a confirmation message when I have set 100a as important and set try to submit the 'Edit item' form when 100a is blank. There does not appear to be JS errors in the console. Cheers, Alex -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15679] New: Reset item level hold back to record level hold without deleting and readding the hold
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '19

26 Jul '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15679 Bug ID: 15679 Summary: Reset item level hold back to record level hold without deleting and readding the hold Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Right now, if a hold is tied to a specific item (for any number of reasons), and it needs to be set back to a title level hold, you have to delete and readd the hold. This is cumbersome enough, but it's even more cumbersome when a record has multiple holds (especially 20+), and the hold has to be replaced and manually back in its original priority order. It would be nice if Koha could allow you to reset a hold back to record level after it's been placed, for all cases, including when it's in transit for a patron. Situations arise where an item arrives damaged or is lost in transit and a new item is needed to fulfill the hold. There should probably be a permission to control access to this proposed functionality, like the existing modify_holds_priority permission. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5