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

[Bug 3516] Display picture of patrons in OPAC
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '12

05 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3516 Paul Poulain <paul.poulain(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4246] Koha support for Itiva Talking Tech phone notification service
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '12

05 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4246 Kyle M Hall <kyle.m.hall(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #8012|0 |1 is obsolete| | --- Comment #5 from Kyle M Hall <kyle.m.hall(a)gmail.com> --- Created attachment 8014 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8014&action=edit Talking Tech Support - Phase I Implements support for Talking Tech I-tiva phone notification for OVERDUE, PREDUE and HOLD notifications. Overdues respect triggers as configured for the patron's branch. Predue and Holds notifications respect patron's messaging preference choices. A new column for phone notification is added if the TalkingTechItivaPhoneNotification system preference is turned on Record of phone messages being sent to patrons is added to the patron's Notices tab; notice of success or failure can be retrieved from I-tiva. See the TalkingTech.README for installation and set-up instructions. Aside from the control system preference, and the necessary changes to Messaging Preferences forms to make use of phone notifications, the bulk of the code resides in external cronjobs. TalkingTech_itiva_outbound.pl generates the Spec C file to send to I-tiva. Actual transmission of the file must be handled by the system administrator. TalkingTech_itiva_inbound.pl processes the received Results file from I-tiva. Getting the file from I-tiva to Koha is the job of the system administrator, as well. Both scripts have a --help option with full documentation. The only necessary change to core Koha behavior is in C4::Letters::EnqueueLetter. The return value was changed from 0 or 1 (successful addition of letter to message_queue or not), to the actual insert ID of the letter. This was required by the outbound script to present a unique Transaction ID for the notice added to the patron's record (so a 'sent' or 'failed' status could be updated). Since the dbh and sth are not shared, and the last_insert_id() command is table-specific, this should be thread-safe. No changes are necessary to any parts of Koha, as all usage of EnqueueLetter currently ignores the return value. To Test: 1. Turn on TalkingTechItivaPhoneNotification system preference 2. Verify that 'phone' is now a valid notification option for patrons on both staff and OPAC side 3. Attempt to set a 'phone' preference for PREDUE or HOLD messaging; attempt should succeed 4. Set up the patron for notices to triggers: a. include checked out items due in a range of days, including the value set up in their messaging preferences. b. place several holds, some in position, others waiting for pickup, others in transit. c. set the patron up to have overdues, overdue by a range of days that includes the delay values for the patrons branch and categorycode 5. Run TalkingTech_itiva_outbound.pl --type=RESERVE --type=PREOVERDUE --type=OVERDUE --outfile=/tmp/talkingtechtest.csv The resulting talkingtechtest.csv file should include all the items due on X days (where X is the patrons' preference), and none of the ones due in other increments. Similarly, overdues messages should be added for each item due by a delay value as configured; overdues of other numbers of days should be ignore. Holds that are waiting pick up or in transit should have messages, those still pending should not. Messages should be added to the patron's notices tab for each issue sent. Verify these messages exist, and all Notices tokens are replaced with appropriate information. Repeat, this time with 4c making use of the default branch overdue triggers, instead of branch-specific triggers. To test the inbound script, create a CSV with rows in the format "<<Message_id>>","<<SUCCESS or FAIL>>" Message ID should correspond to the final column of the talkingtechtest.csv file (the transaction id) for the message. Primary Authorship: Ian Walls Additional modifications: Kyle M Hall -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4246] Koha support for Itiva Talking Tech phone notification service
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '12

05 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4246 Kyle M Hall <kyle.m.hall(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #7965|0 |1 is obsolete| | -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4246] Koha support for Itiva Talking Tech phone notification service
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '12

05 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4246 --- Comment #4 from Kyle M Hall <kyle.m.hall(a)gmail.com> --- Created attachment 8012 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8012&action=edit Talking Tech Support - Phase I Implements support for Talking Tech I-tiva phone notification for OVERDUE, PREDUE and HOLD notifications. Overdues respect triggers as configured for the patron's branch. Predue and Holds notifications respect patron's messaging preference choices. A new column for phone notification is added if the TalkingTechItivaPhoneNotification system preference is turned on Record of phone messages being sent to patrons is added to the patron's Notices tab; notice of success or failure can be retrieved from I-tiva. See the TalkingTech.README for installation and set-up instructions. Aside from the control system preference, and the necessary changes to Messaging Preferences forms to make use of phone notifications, the bulk of the code resides in external cronjobs. TalkingTech_itiva_outbound.pl generates the Spec C file to send to I-tiva. Actual transmission of the file must be handled by the system administrator. TalkingTech_itiva_inbound.pl processes the received Results file from I-tiva. Getting the file from I-tiva to Koha is the job of the system administrator, as well. Both scripts have a --help option with full documentation. The only necessary change to core Koha behavior is in C4::Letters::EnqueueLetter. The return value was changed from 0 or 1 (successful addition of letter to message_queue or not), to the actual insert ID of the letter. This was required by the outbound script to present a unique Transaction ID for the notice added to the patron's record (so a 'sent' or 'failed' status could be updated). Since the dbh and sth are not shared, and the last_insert_id() command is table-specific, this should be thread-safe. No changes are necessary to any parts of Koha, as all usage of EnqueueLetter currently ignores the return value. To Test: 1. Turn on TalkingTechItivaPhoneNotification system preference 2. Verify that 'phone' is now a valid notification option for patrons on both staff and OPAC side 3. Attempt to set a 'phone' preference for PREDUE or HOLD messaging; attempt should succeed 4. Set up the patron for notices to triggers: a. include checked out items due in a range of days, including the value set up in their messaging preferences. b. place several holds, some in position, others waiting for pickup, others in transit. c. set the patron up to have overdues, overdue by a range of days that includes the delay values for the patrons branch and categorycode 5. Run TalkingTech_itiva_outbound.pl --type=RESERVE --type=PREOVERDUE --type=OVERDUE --outfile=/tmp/talkingtechtest.csv The resulting talkingtechtest.csv file should include all the items due on X days (where X is the patrons' preference), and none of the ones due in other increments. Similarly, overdues messages should be added for each item due by a delay value as configured; overdues of other numbers of days should be ignore. Holds that are waiting pick up or in transit should have messages, those still pending should not. Messages should be added to the patron's notices tab for each issue sent. Verify these messages exist, and all Notices tokens are replaced with appropriate information. Repeat, this time with 4c making use of the default branch overdue triggers, instead of branch-specific triggers. To test the inbound script, create a CSV with rows in the format "<<Message_id>>","<<SUCCESS or FAIL>>" Message ID should correspond to the final column of the talkingtechtest.csv file (the transaction id) for the message. Primary Authorship: Ian Walls Additional modifications: Kyle M Hall -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bugzilla] Your account koha-bugs@lists.koha-community.org is being impersonated
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '12

04 Mar '12

Chris Cormack <chris(a)bigballofwax.co.nz> has used the 'sudo' feature to access Bugzilla using your account. Chris Cormack <chris(a)bigballofwax.co.nz> provided the following reason for doing this: Setting email If you feel that this action was inappropriate, please contact chris(a)bigballofwax.co.nz. For more information on this feature, visit <http://bugs.koha-community.org/bugzilla3/page.cgi?id=sudo.html>.

1 0

[Bug 4045] No check for maximum number of allowed holds.
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '12

02 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4045 --- Comment #27 from Liz Rea <wizzyrea(a)gmail.com> --- So to test this we need to * make sure multi holds beyond maxreserves are not allowed * make sure single holds that would put you over maxreserves are disallowed in both intranet and OPAC is that all? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 5503] New: comments shouldn't show patron's full name
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '12

02 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5503 Summary: comments shouldn't show patron's full name Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: OPAC Comments AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When leaving comments in the OPAC it shows the patron's full name. This is done without asking the patron if they approve of sharing that info. Either it should show the first name last initial, patron initials, or should give the patrons a choose of what name to show (like on most blogging applications). No matter what we shouldn't show the full name of the patron on the OPAC for all to see without asking them if it's okay. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 29

[Bug 3216] UNIMARC author facets
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '12

02 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3216 --- Comment #14 from Ian Walls <koha.sekjal(a)gmail.com> --- Testing on a UNIMARC sandbox: searching kw,wrdl: rue and au,wrdl: alain serres from advanced search yields 28 results. searching just kw,wrdl: rue yields 192 results. But clicking the "Serres, Alain" facet gives only 1 result! The query is constructing as limit=au:serres, alain, which could be the problem. I'm not sure if this is because the ICU requirements are incompatible with the sandbox set up, or if the patch is failing to work as expected. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7640] New: runtime calendar
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '12

02 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7640 Priority: P5 - low Change sponsored?: --- Bug ID: 7640 Assignee: gmcharlt(a)gmail.com Summary: runtime calendar QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Reports Product: Koha It would be great if we could use runtime parameters to get a GUI calendar to show up in addition to being able to type dates. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 4530] Circulation & fines rules aren't always applied from most specific to less specific
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '12

02 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4530 --- Comment #23 from Gaetan Boisson <gaetan.boisson(a)biblibre.com> --- I think we really need 0 and NULL to be treated differently. It is important for instance to define that a type of document cannot be issued to a certain category of patrons, without falling back on a more generic rule that would allow it. Sometimes we also want to define that 0 books of that type can be issued to a patron category, with a loan period of X days : if we force the loan on an exceptional basis, the length of the loan will already be defined. Here is my test plan so far: i have defined 8 rules, matching the 8 possibilities. For every rule i put the same value in each field: 8 for same library, same patron type, same item type 7 for same library, same patron type, all item types 6 for same library, all patron types, same item type 5 for same library, all patron types, all item types 4 for all libraries, same patron type, same item type 3 for all libraries, same patron type, all item types 2 for all libraries, all patron types, same item type 1 for all libraries, all patron types, all item types the i tweak to put NULL (or 0 at the moment) at different places, loan some books and see what happens. So far one thing that turned out not to work out was the number of renewals : it falls straight back to rule 3, and if i void rule 3 it falls back to rule 1, ignoring rule 2. There are a lot of possibilities to test and i am not done yet... -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0