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

[Bug 8361] Issuing rule if no rule is defined
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8361 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #59086|0 |1 is obsolete| | --- Comment #15 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 59087 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=59087&action=ed… Bug 8361 (QA Followup) Add warnings - Added message to circulation.tt to warn if rule undefined for patron/itemtype combination To test: 1 - Remove all circ rules 2 - Add one rule 3 - Checkout to patron an itemtype that is outside of rule defined above 4 - Note explanation that no rule is defined -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8361] Issuing rule if no rule is defined
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8361 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #58967|0 |1 is obsolete| | --- Comment #14 from Nick Clemens <nick(a)bywatersolutions.com> --- Created attachment 59086 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=59086&action=ed… Bug 8361 (QA Followup) Add warnings - Added message to circulation.tt to warn if rule undefined for patron/itemtype combination To test: 1 - Remove all circ rules 2 - Add one rule 3 - Checkout to patron an itemtype that is outside of rule defined above 4 - Note explanation that no rule is defined -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8361] Issuing rule if no rule is defined
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8361 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 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #29 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Alex Arnaud from comment #28) > > Hello Sonia, > > I'm not comfortable with having two expirationdate fields. And i think we > can spare ourselves from adding a new field by doing what Marcel suggests > previously: > override the expiration date only if the one requested by the patron is > before the calculated one. > > My two cents Yeah, sounds better :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #28 from Alex Arnaud <alex.arnaud(a)biblibre.com> --- (In reply to Koha Team Lyon 3 from comment #27) > Hello, > I'm afraid that we are mired in a never ending discussion. > For me, as I have already sayd, there's no reason to keep expirationday > after the hold is available and waiting to be picked up, as this date is > meaning for users "I don't need this hold if it isn't available for me after > this date". > > But, I can see that it bothers Marcel so I propose that we try to find new > solutions to help this feature to be pushed in Koha (because it's really > important for many libraries). > > So, I don't know if it's valuable but it seems to me that it could at least > be simple, what do you think about creating a new field where we can stock a > "pickupexpirationdate" or something like that ? > > Marcel, Alex ? Is it possible ? Hello Sonia, I'm not comfortable with having two expirationdate fields. And i think we can spare ourselves from adding a new field by doing what Marcel suggests previously: override the expiration date only if the one requested by the patron is before the calculated one. My two cents -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #27 from Koha Team Lyon 3 <koha(a)univ-lyon3.fr> --- Hello, I'm afraid that we are mired in a never ending discussion. For me, as I have already sayd, there's no reason to keep expirationday after the hold is available and waiting to be picked up, as this date is meaning for users "I don't need this hold if it isn't available for me after this date". But, I can see that it bothers Marcel so I propose that we try to find new solutions to help this feature to be pushed in Koha (because it's really important for many libraries). So, I don't know if it's valuable but it seems to me that it could at least be simple, what do you think about creating a new field where we can stock a "pickupexpirationdate" or something like that ? Marcel, Alex ? Is it possible ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16638] New: Business::ISBN versioning scheme says it needs upgrade, but doesn't
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16638 Bug ID: 16638 Summary: Business::ISBN versioning scheme says it needs upgrade, but doesn't Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: gmcharlt(a)gmail.com Reporter: vanoudt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Busy upgrading to 16.05 at the moment, and have noticed an issue with Business::ISBN. Here on Fedora (using my KohaExtra repository: dnf copr enable vanoudt/KOHAExtra ) Business::ISBN is at version 2.010. That's a 10 at the end, as opposed to a 5 which the required version (2.05) asks for. It's a weird numbering scheme, but the changelog shows that 2.010 is actually a later release than 2.05 . Naturally, koha_perl_deps.pl tells me that this module requires updating... but it doesn't. Not sure what the right fix here is... -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 5599] koha_perl_deps.pl and PerlDependencies.pm don' t compare $VERSION numbers correctly
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5599 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- *** This bug has been marked as a duplicate of bug 17880 *** -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 11761] Multiple notifications for borrowers if checked out from many branches during one day. (caused by overdue_notifications.pl)
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11761 --- Comment #1 from Ray Delahunty <r.delahunty(a)arts.ac.uk> --- We are a multi-college library with 6 libraries spread around central London. There is some course overlap and it is NOT unusual for users to visit more than one library in a day. Whether these users are hardcore library addicts is debatable. But we did send out three ODUE emails to one user the other day, each listing the same 9 items as overdue, one email from each of the three libraries this dedicated library user had visited and borrowed items from. Ideally, in multi-library Koha sites the digest emails would become a digest of digests. Ray Delahunty University of the Arts London -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 11911] Purchase suggestions can be accessed by all staff members / no specific permission
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11911 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk --- Comment #5 from Ray Delahunty <r.delahunty(a)arts.ac.uk> --- May I respectfully ask that this bug **not** be fixed to ensure that permissions are checked, without the action in duplicate 15506 being attended to at the same time. Here we are delighted at this permissions bug as only a handful of central office staff have Acquisitions permissions (and hence Purchase Suggestions permissions). We have distributed the link included below out to college library staff at all of our various sites, and this means the staff there can deal with Suggestions themselves without central bibliographic services staff having to be involved. Perhaps Purchase Suggestions permissions belong under Tools, rather than Acquisitions? Ray Delahunty University of the Arts London -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0