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

[Bug 11592] opac detail scripts do not respect MARC tag visibility
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11592 Patrick Robitaille <patrick.robitaille(a)ccsr.qc.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |patrick.robitaille(a)ccsr.qc. | |ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14972] Limit by availability does not return results if *any* items are on-loan or lost
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14972 Sally Healey <sally.healey(a)cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sally.healey@cheshireshared | |services.gov.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6952] have MARC export tool display count of bibs it will export before exporting
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6952 Jeremy Evans <Jeremy.evans(a)nibsc.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Jeremy.evans(a)nibsc.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6936] allow selection by multiple item types or libraries when exporting bibs/ items
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6936 --- Comment #5 from Jeremy Evans <Jeremy.evans(a)nibsc.org> --- We would support this. I just had to run the report 8 times to get the export files needed for 8 item types. It would be much easier to be able to multi-select the item types and get just one output file. In some cases I would also want to be able to filter by shelf location or ccode as well as library/item type. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 6936] allow selection by multiple item types or libraries when exporting bibs/ items
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6936 Jeremy Evans <Jeremy.evans(a)nibsc.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Jeremy.evans(a)nibsc.org --- Comment #4 from Jeremy Evans <Jeremy.evans(a)nibsc.org> --- We would support this. I just had to run the report 8 times to get the export files needed for 8 item types. It would be much easier to be able to multi-select the item types and get just one output file. In some cases I would also want to be able to filter by shelf location or ccode as well as library/item type. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 15438] Checking out an on-hold item sends holder' s borrowernumber in AF (screen message) field.
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA --- Comment #43 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- QA Comment: Looks good to me apart from a few minor comments (see above). Just noting: When the checkout fails, SIP returns a VALID_PATRON response BL=Y. It does not when the checkout is ok. The due date passed in the sip request is simply ignored. If I pass an old date or even an invalid date, the item is still checked out. Opened bug 19276 for error in CanBookBeIssued re statistical patrons. We could perhaps use a unit test that helps us 'force' a policy somehow about the lowercase/uppercase returns from CanBookBeIssued. We are still missing a checkout test in t/db/SIP/Message. No time to write it here. In view of the age of this patch and the attention already given by several people before me, I am passing QA on this patch now too. (The last comment of Kyle could be read as a kind of signoff too btw.) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15438] Checking out an on-hold item sends holder' s borrowernumber in AF (screen message) field.
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 --- Comment #42 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 66983 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=66983&action=ed… Bug 15438: [QA Follow-up] Moving POD statement for CanBookBeIssued The statement for head3 NB ('nota bene'?) looks like a hash key in the list of possible return values for $needsconfirmation. Moved it up and prefixed it with IMPORTANT. Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15438] Checking out an on-hold item sends holder' s borrowernumber in AF (screen message) field.
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #64265|0 |1 is obsolete| | --- Comment #41 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 66982 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=66982&action=ed… Bug 15438 - Checking out an on-hold item sends holder's borrowernumber in AF (screen message) field. The returns from C4::Circulation::CanBookBeIssued used to be structured as a hashref of entries like REASON => { data => 'foo', moredata => 'bar', }; Some entries still are. But many are now REASON => 1, data => 'foo', moredata => 'bar', The sip Checkout routine still assumed the former, as it reports any causes it was not aware of (to maintain support for a changing api) The data fields could leak into the screen message field of the response. e.g. the borrowernumber or surname of the borrower who has a hold on an issued title. Some real messages were getting obscured by this This patch sanatizes the return from from CanBookBeIssued by removing keys which are not all uppercase It also fixes a case where the key's data element was used for the screen message when we should use the key itself Updated the documentation of CanBookBeIssued to flag up the assumption re case and the fact that 3 elements rather than two may be returned The loop through the returned keys was a bit bogus so we now explicitly jump out if noerror is unset Signed-off-by: Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> Tested quite extensively. Test results put on Bugzilla. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15438] Checking out an on-hold item sends holder' s borrowernumber in AF (screen message) field.
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

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

1 0

[Bug 15438] Checking out an on-hold item sends holder' s borrowernumber in AF (screen message) field.
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '17

08 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15438 --- Comment #40 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Think we still need a last; statement after this one too: $self->screen_msg("Item is reserved for another patron upon return."); $noerror = 0; But I tested this situation too. Better to exit the loop rightaway now? No blocker, but theoretically one error could be overwritten by another. -- You are receiving this mail because: You are watching all bug changes.

1 0