October 2017 - Koha-bugs - lists.koha-community.org

[Bug 11976] show issue date instead of received date for serials in opac
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11976 M. Tompsett <mtompset(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #68192|0 |1 is obsolete| | --- Comment #14 from M. Tompsett <mtompset(a)hotmail.com> --- Created attachment 68610 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=68610&action=ed… Bug 11976 - Choose date to display Allows choosing between publication date or receival date (or both) for serials information in the OPAC. Test plan : 0) If you have no serials : a) Create a subscription b) Receive the item, making sure to have a different publication and receival date 1) Visit the OPAC details page for the item you've created 2) Without the patch only the receival date will be displayed 3) Apply patch 4) Run installer/data/mysql/updatedatabase.pl 5) With the patch the publication date and the receival date will be displayed. This can be changed to either (or both) with the 'OPACSerialDisplayPublishedDate' system preference. Signed-off-by: Mark Tompsett <mtompset(a)hotmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 19222] New: Why does dt_from_string not understand yyyy-mm-ddThh:mm: ss ?
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19222 Bug ID: 19222 Summary: Why does dt_from_string not understand yyyy-mm-ddThh:mm:ss ? 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 dt_from_string disregards the time part when there is a T before it. But note that if you print a datetime it actually prints that T. Like: 2017-08-31T13:32:37 A small regex adjustment could be helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 14637] Add patron category fails with MySQL 5.6.26
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14637 --- Comment #20 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Mason James from comment #19) > Pushed to 16.05.x, for 16.05.08 release No! No method checkprevcheckout! at t/db_dependent/Koha/Patron/Categories.t line 35. No method checkprevcheckout! at t/db_dependent/Koha/Patron/Categories.t line 35. No method checkprevcheckout! at t/db_dependent/Koha/Patron/Categories.t line 40. No method checkprevcheckout! at t/db_dependent/Koha/Patron/Categories.t line 40. No method checkprevcheckout! at t/db_dependent/Koha/Patron/Categories.t line 55. No method checkprevcheckout! at t/db_dependent/Koha/Patron/Categories.t line 55. [13:33:25] t/db_dependent/Koha/Patron/Categories.t ...................... ok 977 ms You should run the tests (at least) when you backport patches. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9302] Add ability to merge patron records
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9302 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #66617|0 |1 is obsolete| | --- Comment #10 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 68606 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=68606&action=ed… Bug 9302 - Add ability to merge patron records It would be great if there were a merge patrons feature. If you accidentally end up with one patron with two cards it would be nice to merge their records together so that you don't lose their history or holds or anything. This patch adds a basic patron merge feature. It attempts to relink all patron related tables from the patron(s) to be merged. It does not attempt to relink librarian account related tables at this time. This feature does not attempt to automatically resolve issues such as duplicate holds. Such a feature could build upon this one though. Test Plan: 1) Apply this patch 2) Find two or more patrons 3) Perform a patron search that will bring them up on the same page of results, or add them all to a list of patrons. 4) Use the 'merge' button to begin the merging process 5) Choose a patron to keep 6) Verify the deleted patrons data ( checkouts, holds, etc ) are now linked to the kept patron -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9302] Add ability to merge patron records
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9302 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9302] Add ability to merge patron records
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9302 --- Comment #9 from Kyle M Hall <kyle(a)bywatersolutions.com> --- (In reply to Tomás Cohen Arazi from comment #8) > Kyle, I'm failing it so it is obvious that some changes are needed for its > inclusion! > > (In reply to Jonathan Druart from comment #7) > > Readonly: see bug 16588 > > We are trying explicitly to get rid of Readonly, dicussion on that bug. Will fix! > > Koha::Patrons->merge: See 15336, it adds a > > Koha::Acquisition::Bookseller->merge_with #consistency > > Self explanatory! This one isn't so easy for me ; ) Bookseller->merge_with is a method for a single object, and acts upon it. Koha::Patrons->merge is a method that accepts a patron, and a list of patrons to merge into. I think it's actually better because the parameters make is clear which patron will be retained. With Bookseller->merge, I cannot tell which Bookseller will be removed and which will be kept without reading the code. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4461] Context-sensitive report a problem screen
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4461 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|koha-bugs(a)lists.koha-commun |nick(a)bywatersolutions.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 4461] Context-sensitive report a problem screen
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4461 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick(a)bywatersolutions.com Status|Signed Off |Failed QA --- Comment #17 from Nick Clemens <nick(a)bywatersolutions.com> --- Hi Aleisha, 1 - Need tests for new Objects 2 - With 'DefaultReplyTo' unset it is still 'defined' so I get the library email option even when none are set. 3 - If not logged in I still see the report form, I think I should just get the warning to log in. 3 - Similarly, if both emails are undefined maybe I shouldn't get the form at all since I can't submit? 4 - Rather than a JS function to disable the submit button can we just disable the input on the dropdown and add a tooltip? Or only provide a dropdown if there is a choice possible? The warning about missing emails seems more appropriate for the about page than the users. 5 - The new preference is defaulting to 'Allow' it should default to 'Don't Allow' -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 11512] Forced holds that violate issuing rules will never be filled
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11512 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #68594|0 |1 is obsolete| | --- Comment #5 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 68595 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=68595&action=ed… Bug 11512 - Forced holds that violate issuing rules will never be filled Currently in Koha, if you choose to force a hold from the staff side that would contravened the current issuing rules, that hold will never be filled, as it is always skipped over by CheckReserves. This patch disallows overrideing except for tooManyReserves which are the only overridden holds that will be trapped. Test Plan: 1) Apply this patch 2) Attempt to override hold placement, only placements where the patron has too many holds already should be allowed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11512] Forced holds that violate issuing rules will never be filled
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11512 --- Comment #4 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 68594 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=68594&action=ed… Bug 11512 - Forced holds that violate issuing rules will never be filled Currently in Koha, if you choose to force a hold from the staff side that would contravened the current issuing rules, that hold will never be filled, as it is always skipped over by CheckReserves. This patch disallows overrideing except for tooManyReserves which are the only overridden holds that will be trapped. Test Plan: 1) Apply this patch 2) Attempt to override hold placement, only placements where the patron has too many holds already should be allowed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0