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

[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 10 Jul '12

10 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 10 Jul '12

10 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

[Bug 8301] New: Display additional system information (preferences) on About page to minimize support cases
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '12

10 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8301 Priority: P5 - low Change sponsored?: --- Bug ID: 8301 Assignee: nengard(a)gmail.com Summary: Display additional system information (preferences) on About page to minimize support cases Severity: enhancement Classification: Unclassified OS: All Reporter: veron(a)veron.ch Hardware: All Status: NEW Version: master Component: About Product: Koha Created attachment 10450 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10450&action=edit Screenshot with warnings regarding preferences on About page To minimize support questions regarding common mistakes, the About page should have an additional tab that displays warnings if depractated and/or mutual excluding system preferences are used. Example: Bug 8298 Can't call method "subfield" on an undefined value at Biblio.pm (sub _AddBiblioNoZebra) See screenshot attached. Marc -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 4838] New: Repeated authority headings break biblio record data entry form
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '12

09 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4838 Summary: Repeated authority headings break biblio record data entry form Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Cataloging AssignedTo: frederic(a)tamil.fr ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 If you have an authority, with more than one heading, for example a UNIMARC multilingual author: 200 $7 da $a 原 $b 純輔 200 $7 ba $a Hara $b Junsuke In data entry form, you click on ..., you find such an authority, you click on Choose. The result is messed up. $9 is not copied and $7 content modify $9 code into $ba. -- 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 23

[Bug 8303] New: Hide login box in OPAC with system preference.
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '12

09 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8303 Priority: P5 - low Change sponsored?: --- Bug ID: 8303 Assignee: oleonard(a)myacpl.org Summary: Hide login box in OPAC with system preference. Severity: enhancement Classification: Unclassified OS: All Reporter: meenakshi.r(a)osslabs.biz Hardware: All Status: NEW Version: master Component: OPAC Product: Koha Hide login box in OPAC with system preference. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 7299] New: ILSDI HoldItem service does't set the itemnumber in reserves table
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '12

07 Jul '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7299 Bug #: 7299 Summary: ILSDI HoldItem service does't set the itemnumber in reserves table Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: alex.arnaud(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com The itemnumber is not passed in AddReserve function because parameters are not used correctly in C4/ILSDI.Services.pm. We have: $branch, $borrowernumber, $biblionumber, $constraint, $bibitems, $priority, $notes, $title, $checkitem, $found Instead of: $branch,$borrowernumber,$biblionumber,$constraint,$bibitems,$priority,$resdate,$expdate,$notes,$title,$checkitem,$found Probably because function Addreserve has changed. -- 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 15