February 2015 - Koha-bugs - lists.koha-community.org

[Bug 10861] New: Add a check on cardnumber length
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '15

13 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10861 Bug ID: 10861 Summary: Add a check on cardnumber length Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries would like to add a check on the cardnumber length. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 7561] New: cannot fast catalog with fast cataloging permissions
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '15

11 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7561 Bug #: 7561 Summary: cannot fast catalog with fast cataloging permissions Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 - low Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com If you have a user with fast cataloging permissions and no other cataloging permissions the user can catalog the bib record using fast cataloging, but when they click save they are not brought to the item record anymore they're brought to the normal view. Fast cataloging is both bib and item record for a fast record so it can be checked out and this is how it was in 3.6 - but appears to have changed in master and a later 3.6.x release. -- 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 25

[Bug 7480] New: authorisedbyname filled twice in neworderempty.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '15

11 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7480 Bug #: 7480 Summary: authorisedbyname filled twice in neworderempty.pl Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Acquisitions AssignedTo: adrien.saurat(a)biblibre.com ReportedBy: adrien.saurat(a)biblibre.com QAContact: koha.sekjal(a)gmail.com In the "neworderempty.pl" file, as we are filling the template->param(*) info beginning on line 346, we have a value appearing twice: - in line 359, authorisedbyname => $basket->{'authorisedbyname'}, - in line 365, authorisedbyname => $borrower->{'firstname'} . " " . $borrower->{'surname'}, Moreover, this line 365 generates log lines like the following: [Tue Jan 31 14:39:41 2012] neworderempty.pl: Use of uninitialized value in concatenation (.) or string at /home/asaurat/workspace/versions/community/acqui/neworderempty.pl line 346. [Tue Jan 31 14:39:41 2012] neworderempty.pl: Use of uninitialized value in concatenation (.) or string at /home/asaurat/workspace/versions/community/acqui/neworderempty.pl line 346. These log entries are easy to correct if we keep the $borrower version, but that's my question: which line should we keep? Or maybe both values can be ok but one has priority over the other one? This authorisedbyname variable is linked to a "Managed by:" label in the template. -- 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 16

[Bug 8050] New: debian/build-git-snapshot should warn user if it fails
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '15

11 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8050 Priority: P5 - low Change sponsored?: --- Bug ID: 8050 Assignee: robin(a)catalyst.net.nz Summary: debian/build-git-snapshot should warn user if it fails Severity: normal Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: Packaging Product: Koha The script debian/build-git-snapshot returns success even if the package building fails. Automating package build requires some sort of feedback if the package build fails, preferably a non-success return value for the debian/build-git-snapshot script. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 9874] New: Adding subfield «ampersand» produce unexpected behaviours
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '15

10 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 Bug ID: 9874 Summary: Adding subfield «ampersand» produce unexpected behaviours Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: pablo.bianchi(a)gmail.com On Koha v3.10.03.000, one of the librarians thought that English letters and numbers where not enough on 952 holdings subfield, so created new subfields on one the framework. The problem is, choosing ampersand, "&" produce unexpected behaviours, like not been able to delete the subfield, or showing the that subfield while trying to see the others. Creating subfields with other strange characters, like "ñ" (http://en.wikipedia.org/wiki/%C3%91) can be handled by Koha. In other words, table marc_subfield_structure, tagfield=952 (or any?), frameworkcode=MYFW (or any), produce: tagsubfield=& The solution is going to the table and removing the row manually (SQL) The link to remove that subfield might give a clue of the problem, just after tagsubfield http GET parameter: http://myserver:8080/cgi-bin/koha/admin/marc_subfields_structure.pl?op=dele… Should not validated Koha what subfields will create? -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 9709] New: actual cost staying zero
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '15

10 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9709 Bug ID: 9709 Summary: actual cost staying zero Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.8 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com It looks like when you are going through the receiving process that the Actual Cost field is not being updated as it has in the past. It is filled in as zero rather than defaulting to the Estimated Cost. Because of this, if you don't change it, it shows that it didn't cost anything, and the Total ends up being zero. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 9853] New: Overdues fine cap empty in circulation rules means fines accrue forever
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '15

10 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9853 Bug ID: 9853 Summary: Overdues fine cap empty in circulation rules means fines accrue forever Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We noticed today while testing overdues and fines, that leaving the overdues fine cap empty means that fines will accrue indefinitely. Before this value was moved to the circulation matrix it came with a predefined value in the sysprefs, so we never ran into this. I am not sure how we can resolve this, but for people just starting using fines this behaviour should at least be documented and it may also be good to have some kind of warning. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 5458] New: length of items.ccode disagrees with authorised_values.authorised_value
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '15

09 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5458 Summary: length of items.ccode disagrees with authorised_values.authorised_value Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Database AssignedTo: gmcharlt(a)gmail.com ReportedBy: pete.huerter(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Koha allows you to define an authorised value having length 80, but then you can't use it. Here is why: The SQL field items.ccode is a varchar(10). The SQL field authorised_values.authorised_value is a varchar(80). Therefore the authorised value is truncated to length 10 in items.ccode and the mapping from authorised value to description string fails in Koha. Not sure how this change will "bubble up" in Koha but the change to the table schema seems straightforward: increase the size of items.ccode to varchar(80). This is preferable to shortening authorised_values.authorised_value since we have many category codes (CCODE) that are longer than length 10. -- 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 13302] New: Use CSS3 ellipsis for email address in staff client patron sidebar
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '15

09 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13302 Bug ID: 13302 Summary: Use CSS3 ellipsis for email address in staff client patron sidebar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The solution which fixed Bug 3256 back in 2009 can be replaced with a more modern CSS3 technique. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 13349] New: Allow library code to display against users pending changes
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '15

09 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13349 Bug ID: 13349 Summary: Allow library code to display against users pending changes Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When OPACPatronDetails is set to Allow in a multi-library environment, it is sometimes useful if the library of the user submitting the change is visible to the staff member approving the change, so that each library can approve or deny the request from their own patrons. The attached patch corrects that. To test: Ensure OPACPatronDetails is set to enabled Apply the patch Log into the OPAC and update your patron details (address, phone number etc) Log into the staff client and view pending patron changes. The branchcode of the library to which the patron belongs should display next to the user's name. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18