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

[Bug 4319] waiting items cannot be reserved
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '17

27 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4319 --- Comment #57 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Conflicts now with just pushed 18547 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4319] waiting items cannot be reserved
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '17

27 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4319 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=18547 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14769] Authorities merge: Set correct indicators in biblio field
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '17

27 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14769 --- Comment #12 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Janusz Kaczmarek from comment #10) > Hello to all. To not open a new bug I would like to submit here a patch > that should fix this painful and far-too-long-still-not-resolved issue. The > proposed approach relies on authority records (which should be > correct--that's exactly why they are called 'authority' records). > Especially MARC 21 case, as stated by Zeno, is more complex, specially for > 6XX (2nd ind., $2 subfield etc.) > > To test -- have some authority recs. with different tags (eg. 100, 130, > 150), use them in biblio, especially in 6XX, 7XX (setting 2nd ind). > Have running indexer and proper value of AuthorityMergeLimit, i.e. not 0. > Then play with indicators in authorities. For MARC 21 auth used in 6XX > play also with 008/11 and 040 $f (if 008/11 set to 'z'). Have a look > at the results in biblio (see subfield $2 in MARC 21 6XX if 008/11 = z > and 040 $f defined). Hi Janusz Thx for submitting this proposal. It really looks interesting. Will need more time to have a closer look, but I am glad that we take a next step. Quick question: The patch is MARC21 oriented; what about the UNIMARC side ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7046] subscription renewal period should be a pull down
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '17

27 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7046 Alex Buckley <alexbuckley(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 7046] subscription renewal period should be a pull down
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '17

27 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7046 --- Comment #6 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 69356 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=69356&action=ed… Bug 7046 - Implemented dropdown sub length element To make this work I moved the _get_sub_length function from subscription-add.pl to C4/Serials.pm so that the subscription-renew.pl script could also call it to store the sublength for the appropriate field of the subscriptions database table. Test plan: 1. Create a subscription and notice that there is a dropdown box for sub length containing the values: issues, weeks, months 2. Renew the subscription and notice that there are 3 input text boxes: 'number of num', 'number of weeks' and 'number of months' 3. Input a 'Number of weeks' value of 2 4. Query the subscription database table and notice that the value of 2 has been stored in the weeklength field for the subscription record you just renewed 5. Apply the patch 6. Renew the subscription and notice that there is now a sublength dropdown box containing issues, weeks and months 7. Set the month value to 3 8. Query the database and notice that 3 was stored in the monthlength field for the subscription record 9. Create a new subscription and select the sub length values of issues and 3 10. Query the database and notice that the numberlength field for the subscription you just created is set to 3 showing that the sublength dropbox is still working for creating a new subscription Sponsored-By: Catalyst IT -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 7046] subscription renewal period should be a pull down
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '17

27 Nov '17

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

1 0

[Bug 7046] subscription renewal period should be a pull down
by bugzilla-daemon＠bugs.koha-community.org 27 Nov '17

27 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7046 --- Comment #5 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Created attachment 69355 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=69355&action=ed… Bug 7046 - Added subscription length dropdown box -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 7143] Bug for tracking changes to the about page
by bugzilla-daemon＠bugs.koha-community.org 26 Nov '17

26 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7143 --- Comment #379 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Jonathan Druart from comment #378) > Created attachment 69351 [details] [review] > Bug 7143: Update timeline (2 new devs) Patch pushed to master for 17.11. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 7143] Bug for tracking changes to the about page
by bugzilla-daemon＠bugs.koha-community.org 26 Nov '17

26 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7143 --- Comment #378 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 69351 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=69351&action=ed… Bug 7143: Update timeline (2 new devs) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 19626] New: Database update for bug 12063 incorrectly calculates expirationdate for holds
by bugzilla-daemon＠bugs.koha-community.org 26 Nov '17

26 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19626 Bug ID: 19626 Summary: Database update for bug 12063 incorrectly calculates expirationdate for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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 Logic in short seems to be: 1 - Does hold already have an expirationdate? a- Keep it if before calculated expirationdate 2 - If not 1 then calculate expiration as curdate + delay (+ holidays if pref) The problem is, before 12063 waiting holds didn't have an expirationdate, so a hold that has been waiting for 2 months will now get a waiting date after the upgrade. I think line 14374 should be: my $expirationdate = dt_from_string($hold->waitingdate); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14