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

[Bug 7660] Enhanced messaging preferences are not set when creating a child patron from the adult
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '19

29 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7660 jdemuth(a)roseville.ca.us <jdemuth(a)roseville.ca.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdemuth(a)roseville.ca.us -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13695] Allow ISBD format export
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '19

29 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13695 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |23174 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23174 [Bug 23174] Default (OPAC)ISBD contains <br> tags that print in ISBD download -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23188] New: Holds Column in Receipt Page sorts oddly
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '19

29 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23188 Bug ID: 23188 Summary: Holds Column in Receipt Page sorts oddly Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In the acquisitions module, when viewing an invoice - and choosing to view this in the Receipt page option, there is a column called Holds. If any record on this receipt has a hold this number will be displayed. There is a tiny carrot to allow the user to change the order of this view to see the most holds first. Unfortunately, Koha displays the holds in a fashion such as 0/1. The first number is the item levels hold and the second number is the total number of holds on the record (or in this case, the bib level hold). The sorting will only sort on the first number and if a library only does bib level holds, the sort will never be accurate. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 19812] New: Holds count in "Already received" table has confusing and unexpected values
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '19

29 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19812 Bug ID: 19812 Summary: Holds count in "Already received" table has confusing and unexpected values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In acqui/parcel.pl both the "Pending orders" and "Already received" tables show how many holds there are for the given record. However, the count of holds in the "Pending orders" table confuses librarians because it only lists holds for the particular items in the orderline. Due to that, the holds column may show 0 holds even if there are a dozen record level holds for that bib! This is not what librarians seem to expect, instead it seems that the same total holds in the "Pending orders" table would be preferred. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 12537] editions tab showing on bibs with more than one ISBN
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '19

28 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12537 Arthur Bousquet <arthur.bousquet(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #90629|0 |1 is obsolete| | --- Comment #6 from Arthur Bousquet <arthur.bousquet(a)inlibro.com> --- Created attachment 91125 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91125&action=ed… Bug 12537: Don't retrieve XISBN results for the same biblionumber For a biblio with multiple ISBNS we sometimes get our own record back when check XISBN, we should test for this To test: 1 - Edit a record in the catalogue, add two isbns: 0521240670 0521284198 2 - Enable ThingISBN and FRBRizeEditions and OPACFRBRizeEditions 3 - View the record in staff and OPAC 4 - You should see editions tab pointing to the same record 5 - Apply patch 6 - Reload the record details, you should no longer see editions tab 7 - Add the second ISBN to another record 8 - Reload details for original record, you shoudl see editions linking to the record with second ISBN 9 - prove -v t/db_dependent/XISBN.t NOTE: Current tests don't work under elasticsearch, but the code does, tests should be rewritten on another bug Signed-off-by: Mark Tompsett <mtompset(a)hotmail.com> Signed-off-by: Bouzid Fergani <bouzid.fergani(a)inlibro.com> Signed-off-by: Arthur Bousquet <arthur.bousquet(a)inlibro.com> -- 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 28 Jun '19

28 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12949 Nadine Pierre <nadine.pierre(a)InLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nadine.pierre(a)InLibro.com Status|Needs Signoff |Signed Off -- 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 28 Jun '19

28 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12949 Nadine Pierre <nadine.pierre(a)InLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #91057|0 |1 is obsolete| | --- Comment #3 from Nadine Pierre <nadine.pierre(a)InLibro.com> --- Created attachment 91121 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91121&action=ed… Bug 12949: Added syspref to control display of unlinked guarantor When upgrading a child to adult patron the guarantor details are still displayed on the new adult patrons record. This is because upgrading a child to an adult patron involves clearing the borrowers.guarantorid value but not the borrowers.contactname, borrowers.contactfirstname Bug 15928 introduced functionality to display contactname and contactfirstname when no guarantorid exists. This was so unlinked guarantors (non-librart patrons) could be set. The display of guarantor information when the guarantorid has been cleared following upgrading to an adult patron category is confusing, as it appears that the guarantor relationship already exists even though the child has been upgraded to an adult. In this patch we introduce a sytem preference GuarantorsMustBeLinkedToPatronAccount (enabled by default) - which keeps the default Koha functionality introduced by 15928 when the syspref is disabled - to only display gurantor information if a guarantorid exists. 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: SELECT guarantorid, contactname, contactfirstname 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 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 GuarantorsMustBeLinkedToPatronAccount syspref and confirm it is enabled 15. Repeat steps 1-5 and notice that the guarantor information is not displayed on the new adult's record 16. Repeat steps 7-10 and notice that the guarantor information is not displayed on the new adult's record 17. Set GuarantorsMustBeLinkedToPatronAccount syspref to disabled 18. Repeat steps 1-5 and confirm the guarantor information is displayed on the new adult's record (i.e. setting GuarantorsMustBeLinkedToPatronAccount syspref to disabled keeps the current Koha behaviour) 19. Repeat steps 7-10 and confirm the guarantor information is displayed 20. Sign off Sponsored-By: Brimbank Library, Australia Signed-off-by: Nadine Pierre <nadine.pierre(a)inLibro.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 22700] New: Make biblio_metadata prefetchable from Koha::Biblio
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '19

28 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22700 Bug ID: 22700 Summary: Make biblio_metadata prefetchable from Koha::Biblio 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 23201] New: Changing languages on the OPAC redirects to opac-main which logs out SCO/SCI users
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '19

28 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23201 Bug ID: 23201 Summary: Changing languages on the OPAC redirects to opac-main which logs out SCO/SCI users Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Target Milestone: --- When changing languages on the OPAC the SCO user is logged out - this si because we always redirect to opac home when changing. We should preserve current location when switching. To recreate: 1 - enable more than 1 language in opaclanugages syspref 2 - enable opaclanguagedisplay syspref 3 - have WebBasedSelfCheck enabled and setup with AutoSelfCheckUser 4 - go to the SCO: http://localhost:8080/cgi-bin/koha/sco/sco-main.pl 5 - Switch languages 6 - get a log out screen -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 13309] opac-search.pl Holds count incorrect
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '19

28 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13309 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen(a)gmail.com --- Comment #11 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- (In reply to Liz Rea from comment #10) > For my part, I am with Christopher here. I'd like to see a simplified > approach to the results page. Patrons don't need all that information. They > need to know if the book is available now, how many there are, and an idea > about how long it could take to get it. > > Something like > > 10 items, 8 unavailable. > > and a preference whether to show the number of holds outstanding on an item, > because patrons don't need to know how many they can't have because they are > sitting on the hold shelf Let's generate an 'items' index in ES and make use of JOIN operations :-D -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0