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

[Bug 7597] New: fines not recording the right info in the stats table
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7597 Bug #: 7597 Summary: fines not recording the right info in the stats table Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com I did some testing today of paying fines and watched my DB only to find that the data being recorded when writing off a fine is wrong. http://screencast.com/t/XuhUtQRMccr When you write off a fine it's using the wrong branch code and it seems to be writing off the wrong amount altogether. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 26

[Bug 7485] New: Cannot edit barcode on Fast Add
by bugzilla-daemon＠bugs.koha-community.org 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7485 Bug #: 7485 Summary: Cannot edit barcode on Fast Add Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha.sekjal(a)gmail.com When new records use the fast add/ill framework, after initially adding an item record, including its barcode, when you go back to edit the item record, the barcode field is not editable -- in fact, nothing displays in the barcode field! (see attached) I replicated this behavior using both the Fast Cataloging link under Circulation, and by starting a new record from the Cataloging module using the Fast Add framework. I was able to temporarily resolve this for one of our libraries by having her switch the record framework to default. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 10

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

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4246 Nicole C. Engard <nengard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- 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 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4246 Nicole C. Engard <nengard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #8638|0 |1 is obsolete| | --- Comment #11 from Nicole C. Engard <nengard(a)gmail.com> --- Created attachment 9488 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9488&action=edit [SIGNED-OFF] Talking Tech Support - Phase I - Followup - Fix Messaging Preferences There is a flaw in C4::Members::Messaging::GetMessagingPreferences where the system assumes that every transport will use the same letter. This is not necessarily true. Even with the default preferences of just 'email' and 'sms', we should be able to have different letters for each, as one has a maximum character length ( sms ) and one does not. GetMessagingPreferences currently uses the letter code of the last result of its query as the letter code for every transport type. The returned data is a hashref with a key 'transport_types' that is an array of transport_types this borrower has selected for the given alert. This commit modifies GetMessagingPreferences such that the the 'transport_types' array is now a hash where the name of the transport type is now a key to the value of the letter code set for that transport type. It also modifies code calling GetMessagingPreferences where necessary, and as a side benefit will correctly get the letter codes for email and sms correctly, if they are defined differently. http://bugs.koha-community.org/show_bug.cgi?id=4246 Signed-off-by: Nicole C. Engard <nengard(a)bywatersolutions.com> In use in production by two libraries: Middletown and Washoe who give their sign off but don't have git to do so. -- 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 09 May '12

09 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4246 Nicole C. Engard <nengard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #8636|0 |1 is obsolete| | --- Comment #10 from Nicole C. Engard <nengard(a)gmail.com> --- Created attachment 9487 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9487&action=edit [SIGNED-OFF] 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 http://bugs.koha-community.org/show_bug.cgi?id=4246 Signed-off-by: Nicole C. Engard <nengard(a)bywatersolutions.com> Tested and in use in production by two public libraries : Middletown and Washoe. Both have given their sign off, but don't have git to actually sign off. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2774] Path to theme is hard-coded in many places
by bugzilla-daemon＠bugs.koha-community.org 08 May '12

08 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2774 Magnus Enger <magnus(a)enger.priv.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus(a)enger.priv.no --- Comment #2 from Magnus Enger <magnus(a)enger.priv.no> --- (In reply to comment #1) > Have we fixed many of these? Try running this command in the base Koha directory: grep -r --exclude=*.po "/prog/" * Looks like there are quite a few instances left... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7903] New: add an ordernumber column in orders history table
by bugzilla-daemon＠bugs.koha-community.org 08 May '12

08 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7903 Priority: P5 - low Change sponsored?: --- Bug ID: 7903 Assignee: koha(a)univ-lyon3.fr Summary: add an ordernumber column in orders history table QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: koha(a)univ-lyon3.fr Hardware: All Status: NEW Version: rel_3_6 Component: Acquisitions Product: Koha Created attachment 8918 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8918&action=edit Add ordernumber column in order's history table Add an ordernumber column in the search results table of orders. it would be an appreciate help as far as order tracking is concerned. to test : Go to Acquisition homepage : Click on Orders Search Button Type a title or a supplier Submit -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 6372] New: Batch progress bar does not check for 0 size jobs; should be in separate js too
by bugzilla-daemon＠bugs.koha-community.org 08 May '12

08 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6372 Bug #: 6372 Summary: Batch progress bar does not check for 0 size jobs; should be in separate js too Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Batch progress bar does not check for 0 size jobs, and divides by 0, with unpredictable effects. Also, putting progress bar javascript inline makes it impossible to debug. It is possible that this change will improve situation with some bugs reported against background jobs that use progress bar. -- 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 15

[Bug 2399] All status fields in the item edit interface offer two blank/null entries per dropdown instead of one
by bugzilla-daemon＠bugs.koha-community.org 07 May '12

07 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2399 Chris Cormack <chris(a)bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 3413] repeatable tickbox not sticking 1st time round
by bugzilla-daemon＠bugs.koha-community.org 07 May '12

07 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3413 Chris Cormack <chris(a)bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable -- You are receiving this mail because: You are watching all bug changes.

1 0