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

[Bug 8063] New: Hold print notices do not sort by branch
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '12

16 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8063 Priority: P5 - low Change sponsored?: --- Bug ID: 8063 Assignee: gmcharlt(a)gmail.com Summary: Hold print notices do not sort by branch Severity: major Classification: Unclassified OS: All Reporter: joy(a)bywatersolutions.com Hardware: All Status: NEW Version: rel_3_8 Component: Command-line Utilities Product: Koha The gather_print_notices.pl cronjob for printing hold notices mails all notices as one file and does not separate out the notices by branch. For libraries with multiple branches this results in large files being received by individual branches that need to be read/sorted/printed or ignored. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 6394] New: purchase order has french hard coded in
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '12

14 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6394 Bug #: 6394 Summary: purchase order has french hard coded in Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 4235 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4235 purchase order On the purchase order it says 'publié par' - instead of 'published by' I'd recommend we either remove the label all together or have a way to translate that. -- 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 17

[Bug 8005] New: Lost item is not anonymized when checked in
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '12

13 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8005 Priority: P5 - low Change sponsored?: --- Bug ID: 8005 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: Lost item is not anonymized when checked in QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: joy(a)bywatersolutions.com Hardware: All Status: NEW Version: rel_3_6 Component: Circulation Product: Koha When an item is marked as lost and then later checked in, the circulation history is not anonymized, i.e. the patron who 'lost' it, is still shown as the last person to check out the item. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 6296] New: Allow authentication to Koha via PKI / x.509 certificates
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '12

12 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6296 Bug #: 6296 Summary: Allow authentication to Koha via PKI / x.509 certificates Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Authentication AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: dpavlin(a)rot13.org This enhancement will allow authentication to Koha via client side certificates. This can be achieved with apache2 + mod_ssl And the SSLVerifyClient Require directive (Plus a lot more configuration) Configuration for this as part of the install may fall outside the scope of this enhancement, this will be more concerned with dealing with a user that has been authenticated by apache in Koha -- 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 30

[Bug 6233] New: Cannot place holds on items with a status of on-hold if AllowOnShelfHolds is switched off.
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '12

12 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6233 Bug #: 6233 Summary: Cannot place holds on items with a status of on-hold if AllowOnShelfHolds is switched off. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: janet.mcgowan(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com It is not possible to place holds on items that have a status of ‘on hold’ (are available for collection because they are reserved) if the ‘AllowOnShelfHolds’ preference is set to Do not allow. Switching AllowOnShelfHolds off prevents holds from being placed on items that are not checked out. This also means that holds are prevented from being placed on items that are reserved awaiting collection - these aren't checked out, but they aren't available for borrowing either. There seems to be a similarity with bug-4449 - Cannot place holds on unchecked-out missing items if AllowOnShelfHolds is turned off. A workaround for this might be to check out missing items to a dummy patron (thus allowing holds) but this isn't realistic for items that are sitting on a reservations shelf ready for collection. A greater flexibility is requested so so that even though a system is set to Do not AllowOnShelfHolds, it should be possible for patrons to continue to place holds on items that are awaiting collection, even though they are not checked out. -- 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 3

[Bug 6274] New: Permanent storage of user-uploaded files
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '12

11 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6274 Bug #: 6274 Summary: Permanent storage of user-uploaded files Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org C4::UploadedFile has a FIXME to allow for the permanent storage up user-uploaded files. Currently, all files are stored in /tmp, which is wiped on reboot on many (all?) Linux distros. Enabling permanent storage of user-uploaded files would allow for non-database storage of all variety of media. This could be as simple as adding a flag to the new() routine of the UploadedFile object to indicate permanent or temporary. That, along with a directory defined in koha-conf.xml, may be sufficient. -- 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 1

[Bug 7182] New: remove old-style date picker (calendar)
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '12

11 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7182 Bug #: 7182 Summary: remove old-style date picker (calendar) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Architecture, internals, and plumbing AssignedTo: paul.poulain(a)biblibre.com ReportedBy: paul.poulain(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Blocks: 7119 Our date picker is old, unmaintained, and there are a lot of good date picker for jquery. This bug will decide which datepicker we will use and keep track of the work -- 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 4

[Bug 5778] New: Modify DHTMLcalendar function to work with jQueryUI datepicker
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '12

11 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5778 Bug #: 5778 Summary: Modify DHTMLcalendar function to work with jQueryUI datepicker Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Staff Client AssignedTo: paul.poulain(a)biblibre.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 5481 The current calendar widget gets passed a TMPL variable, , with the correct dateformat according to Koha's system preference. We can do the same with the jQueryUI widget, but the variable contents must be different. The current widget looks for a string like: %m/%d/%Y The jQueryUI widget wants something like: m/d/Y -- 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 5

[Bug 6458] New: incorrect parsing result in translation processing
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '12

10 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6458 Bug #: 6458 Summary: incorrect parsing result in translation processing Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: semarie-koha(a)latrappe.fr QAContact: koha-bugs(a)lists.koha-community.org The translation processing issue no error (translate install fr-FR), but the resulting page for almost one template is incorrect (I don't speak about translated string, but structure of resulting file). In 'koha-tmpl/opac-tmpl/prog/en/modules/sco/sco-main.tt', line 135: <input type="button" value="Renew Item" [% UNLESS ( renew ) %] name="confirm"[% END %] class="renew" onclick="this.form.confirmed.value='1';this.form.submit();" /> The result, 'koha-tmpl/opac-tmpl/prog/fr-FR/modules/sco/sco-main.tt', line 88: <input value="Renouveler document" name="confirm" unless="UNLESS" %]="%]" renew="renew" end="END" )=")" type="button" onclick="this.form.confirmed.value='1';this.form.submit();" class="renew" (="(" [%="[%" /> This kind of error arrived two times in 'sco/sco-main.tt'. Note: The result is in reality more complex: 7 lines of 'en' template are mixed in 1 line in 'fr-FR' result template. -- 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 112

[Bug 6782] New: Move autoi member cardnumber generation to occur when record is "Saved"
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '12

10 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6782 Bug #: 6782 Summary: Move autoi member cardnumber generation to occur when record is "Saved" Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: savitra.sirohi(a)osslabs.biz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Currently the card number is generated when the user enters the patron creation form. This creates a problem of concurrency - when two or more simulataneous users are registering members, the error "card no. in use" can occur. This change moves the card number generation to occur after the "Save" button is pressed. -- 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 14