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

[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

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

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14769 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |ASSIGNED --- Comment #5 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- No need to keep this in FQA. We should wait for progress on 9701 first. Setting back to Assigned. -- 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 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14769 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #42197|0 |1 is obsolete| | -- 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 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14769 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy(a)rijksmuseum.nl --- Comment #4 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Good observation from Zeno. When you merge within the same authority type, we can just rely on the indicators of the original biblio field. But we do have a problem when we merge from type say PERSO_NAME to type CORPO_NAME. This is exceptional, but possible. The first indicator does no longer have the same meaning. In that case we should have a fallback if only we had default indicators in the framework. Adding a dependency on bug 9701 therefore. -- 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 17 Jan '17

17 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14769 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |9701 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9701 [Bug 9701] Configure default indicators -- You are receiving this mail because: You are watching all bug changes.

1 0