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

[Bug 5069] New: Authority clean-up scripts
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '15

14 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5069 Summary: Authority clean-up scripts Change sponsored?: --- Product: Koha Version: rel_3_0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P5 Component: Command-line Utilities AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: ccurry(a)amphilsoc.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When we originally migrated our data, we loaded ~ 40,000 auth records corresponding to ~ 200,000 bib records. I ran the link_bibs_to_authorities.pl script, but it appears that we have some bad data in our authorities (or our bibs?), because some did not link correctly. I wonder if there's a way to utilize the process that creates authority records from the appropriate fields during the record creation process to generate authority records from unlinked headings of existing bibs. In addition, we'd like to be able to delete the authorities we imported that have no bibs linked. I asked this question yesterday on IRC#koha and Chris Cormack mentioned that a script could be written for both of these and it "might be a good koha code learning exercise for someone at catalyst." He asked me to submit this enhancement and assign it to him. One thing I should add is this: If there is not already a duplicate auth record checking functionality built into the process which auto-generates authorities during the record creation process, it seems that this would be important for a command line script, since we wouldn't want to create a bunch of identical authorities (which would then not function correctly as authority records). Perhaps the link_bibs_to_authorities.pl script contains the necessary dup finding code? We're running 3.00.05.001 (on Debian Lenny), so it would be useful for us if the scripts were compatible with 3.0 & 3.2. If necessary, we'd be willing to upgrade to 3.00.06 (we're hoping to do so soon, anyway, unless 3.2 becomes stable before we get around to it :) ). -- 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 2

[Bug 7999] New: send test notice
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '15

13 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7999 Priority: P5 - low Change sponsored?: --- Bug ID: 7999 Assignee: henridamien(a)koha-fr.org Summary: send test notice 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: Notices Product: Koha It would be very helpful if we could add a 'send me a test' button on the notices page. This way after you edit a notice template you could generate a notice and have it sent to you (the user who's logged in) so that you could see what it will look like. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 6973] New: Allow reply-to on cart emails to go to the sender of the cart.
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '15

13 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6973 Bug #: 6973 Summary: Allow reply-to on cart emails to go to the sender of the cart. Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org When you send a cart and the person attempts to reply to it, the email goes to the library admin address. This will add a syspref that allows a Reply-To header to be set that will be set to the user of the cart, if they're logged in and have an email address set. Which email address is used will be determined by the AutoEmailPrimaryAddress preference. -- 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 25

[Bug 5377] New: Database fields too small for multiple ISBN and ISSN
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '15

13 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Summary: Database fields too small for multiple ISBN and ISSN Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Database AssignedTo: gmcharlt(a)gmail.com ReportedBy: fridolyn.somers(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Hie, I noticed a wrong behavior in "koha to MARC mapping". Using a mapping for ISBN and ISSN fields, I noticed that fields "isbn" and "issn" where truncated in "biblioitems" table when using multiple values. With multiple values, ISBN and ISSN are separated by a " | ". In fact, "isbn" field is a VARCHAR(30) and "issn" field is a VARCHAR(9). This is far to small. I propose a VARCHAR(255). Regards, -- 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 38

[Bug 9333] New: Confirm close and confirm reopen JavaScript alerts do not work
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '15

13 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9333 Bug ID: 9333 Summary: Confirm close and confirm reopen JavaScript alerts do not work Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org The templates contain JavaScript intended to warn the user before they close or reopen a basket. They never fire because the templates don't trigger them anywhere. If these warnings are still useful they should be enabled. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[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