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

[Bug 12026] Shibboleth auto-provisioning
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12026 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #29 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Perfect Mirko, thanks for cleaning up the rebase. Setting back to SO. -- 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 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 --- Comment #39 from Alex Arnaud <alex.arnaud(a)biblibre.com> --- (In reply to Andreas Hedström Mace from comment #37) > Tested and everything works as intended, except that it is not possible to > cancel holds with the cronjob in > misc/cronjobs/holds/cancel_expired_holds.pl, and thus not possible to set a > cancelation fee. > > However, with the ExpireReservesOnHolidays syspref set to allow, and without > ExcludeHolidaysFromMaxPickUpDelay (set to don’t allow), the hold is > cancelled and sets the fee. > > I don't think this is the desired behaviour (one might want to exclude > holidays but still apply a fee for those who doesn’t pick up a reserved > book), so I'm setting this to patch doesn't apply. > > If someone disagrees, feel free to change the status. Hello Andreas, I didn't managed to reproduce this issue. I have an expired hold. ExpireReservesOnHolidays is set to "don't allow". ExcludeHolidaysFromMaxPickUpDelay is set to "allow", i'm not on a holiday period and ExpireReservesMaxPickUpDelayCharge is set to 11. Launch misc/cronjobs/holds/cancel_expired_holds.pl: 1) hold is canceled, 2) related borrower is charged -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9988] Leave larger authority merges to merge_authorities cronjob ( pref AuthorityMergeLimit)
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 --- Comment #41 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Especially the "Few subtle changes" patch makes a few additional refinements in this regard. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9988] Leave larger authority merges to merge_authorities cronjob ( pref AuthorityMergeLimit)
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 --- Comment #40 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Jacek Ablewicz from comment #39) > For "real" merge usage case (merging two different authority records), if > the merge gets postponed, when merge() is called later by the cron job, > authority record with $mergefrom ID is no longer there (it got deleted from > the database by authorities/merge.pl script ?). This search in postponed > merge() call > > my $authfrom = Koha::Authorities->find($mergefrom); > > will fail, and $authtypefrom | $auth_tag_to_report_from | @record_from would > be empty. I.e.: old authority record heading, stored in the merge requests > table will never be used. > > (but there is a strong possibility I'm very much mistaken about that, > authorities-related code got changed quite a lot lately). The code is designed to overcome this situation. There are tests simulating it too. Take a look :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9988] Leave larger authority merges to merge_authorities cronjob ( pref AuthorityMergeLimit)
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 --- Comment #39 from Jacek Ablewicz <abl(a)biblos.pk.edu.pl> --- For "real" merge usage case (merging two different authority records), if the merge gets postponed, when merge() is called later by the cron job, authority record with $mergefrom ID is no longer there (it got deleted from the database by authorities/merge.pl script ?). This search in postponed merge() call my $authfrom = Koha::Authorities->find($mergefrom); will fail, and $authtypefrom | $auth_tag_to_report_from | @record_from would be empty. I.e.: old authority record heading, stored in the merge requests table will never be used. (but there is a strong possibility I'm very much mistaken about that, authorities-related code got changed quite a lot lately). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11879] Add a new borrower field : main contact method.
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11879 Jesse Maseto <jesse(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jesse(a)bywatersolutions.com Status|Needs Signoff |Patch doesn't apply --- Comment #85 from Jesse Maseto <jesse(a)bywatersolutions.com> --- This patch does not apply. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8010] Search history can be added to the wrong patron
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8010 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8010] Search history can be added to the wrong patron
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8010 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #61251|0 |1 is obsolete| | --- Comment #17 from Marc Véron <veron(a)veron.ch> --- Created attachment 61258 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=61258&action=ed… BUG 8010: Removed Auth2.t Signed-off-by: Marc Véron <veron(a)veron.ch> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8010] Search history can be added to the wrong patron
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8010 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #61223|0 |1 is obsolete| | --- Comment #16 from Marc Véron <veron(a)veron.ch> --- Created attachment 61257 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=61257&action=ed… BUG 8010: Correct a few syntax errors, and moved tests - Tests are now in t/db_dependent/Search/History.t - There were 2 differents sysprefs in sysprefs.sql and in atomicupdate => fixed Signed-off-by: Marc Véron <veron(a)veron.ch> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8010] Search history can be added to the wrong patron
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '17

20 Mar '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8010 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #60187|0 |1 is obsolete| | --- Comment #15 from Marc Véron <veron(a)veron.ch> --- Created attachment 61256 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=61256&action=ed… Added a new syspref to Load history to the next user Added a syspref LoadHistory addSearchHistoryToTheFirstLoggedUser to select if you want the system to add the history of searches performed without session when you log in as registered user. TEST PLAN 1 - Search in the catalogue, check you are not logged 2 - Log in : your last history should appear 4 - Log out 5 - Apply the patch 6 - Repeat 1 and 2 7 - Desactivate the syspref addSearchHistoryToTheFirstLoggedUser 8 - Repeat 1 and 2 : your last history shouldn't appear The Unit test doesn't rollback but delete the added lines : the function get_template_and_user allway sets the autocommit to 1. https://bugs.koha-community.org/show_bug.cgi?id=8010 Tested 3 patches together, works as expected. Signed-off-by: Marc Véron <veron(a)veron.ch> -- You are receiving this mail because: You are watching all bug changes.

1 0