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

[Bug 8955] New: Self checkout should degrade gracefully with JavaScript turned off
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '12

22 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8955 Priority: P5 - low Change sponsored?: --- Bug ID: 8955 Assignee: oleonard(a)myacpl.org Summary: Self checkout should degrade gracefully with JavaScript turned off Severity: normal Classification: Unclassified OS: All Reporter: oleonard(a)myacpl.org Hardware: All Status: ASSIGNED Version: master Component: OPAC Product: Koha I see areas in self-checkout which break if JavaScript is turned off. I think an argument could be made that self-checkout can require JavaScript because the library has control over the machine it is running on. However, the problematic JavaScript dependencies I'm seeing shouldn't really require JS so I think a change is warranted. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 8309] New: Koha namespace organisation, first implementation
by bugzilla-daemon＠bugs.koha-community.org 21 Dec '12

21 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8309 Priority: P1 - high Change sponsored?: --- Bug ID: 8309 Assignee: paul.poulain(a)biblibre.com Summary: Koha namespace organisation, first implementation Severity: enhancement Classification: Unclassified OS: All Reporter: paul.poulain(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Architecture, internals, and plumbing Product: Koha During KohaCon12 hackfest, some of us had a discussion about Koha namespace organisation and content. The result was a wiki page: http://wiki.koha-community.org/wiki/Koha_Namespace_RFC I've investigated this organisation by writing some DBIx::Class & Moose packages. The results are great, a lot of code can be removed, and the code is safer. Note that the patches attached here are just a first draft, not requesting sign-off, just comments ! My feedback of this first try: * defining the schema has been easy, thanks to DBIx::Class documentation. Error messages are very clear and easy to understand for a newbie like me ! * investigating a little bit more, there are many tools/tricks that will make us save a lot of time/lines. Like caching (with DBIx::Class::Cursor::Cached), paging (see http://search.cpan.org/~arodland/DBIx-Class-0.08196/lib/DBIx/Class/Manual/C…, not used in this 1st POC), doing JOIN or finding relations between datas, or returning array of hashrefs (DBIx::Class::ResultClass::HashRefInflator) * cleaning categories.pl resulted in a code that is *much* smaller and readable than the previous one (something like 100 lines removed) -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 6492] New: Deleted biblios cause rebuild_zebra to fail
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '12

20 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6492 Bug #: 6492 Summary: Deleted biblios cause rebuild_zebra to fail Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: ASSIGNED Severity: major Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: pianohacker(a)gmail.com ReportedBy: pianohacker(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com As described by Ian Walls: "On current HEAD, zebraqueue entries that point to deleted biblios are returning an error, and preventing every other done=0 entry from being indexed. I'm not sure if this is occurring after ANY deletion of a biblio, or only through specific vectors like reverting an imported batch, but it's a major problem. ... The exact error being returned by the rebuild_zebra.pl cronjob is: Can't call method 'field' on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 361." -- 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 13

[Bug 8795] New: Just add the login branch In orderreveive.tt
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '12

20 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8795 Priority: P5 - low Change sponsored?: --- Bug ID: 8795 Assignee: koha-bugs(a)lists.koha-community.org Summary: Just add the login branch In orderreveive.tt Severity: enhancement Classification: Unclassified OS: All Reporter: christophe.croullebois(a)biblibre.com Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha The homebranch and holdingbranch ddl in item block are not default selected, they just show the first line. With this patch I just put the default choice as the login branch. To test : without patch the first line of the ddl is shown. With the patch the login branch is shown in homebranch and holdingbranch. thx for testing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 7539] New: BorrowerUnwantedField should also hide fields in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '12

18 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7539 Bug #: 7539 Summary: BorrowerUnwantedField should also hide fields in the OPAC Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: cgi-bin/koha/opac-userupdate.pl OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com The BorrowerUnwantedField preference lets you hide fields from the patron add form, but in the OPAC those fields still show for patrons to update their profile if you allow them to with OPACPatronDetails. The BorrowerUnwantedField should also hide these fields in the OPAC. -- 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 1

[Bug 9144] New: bulkmarcimport.pl - Problem identifying errors
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '12

17 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9144 Bug ID: 9144 Summary: bulkmarcimport.pl - Problem identifying errors Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: vfernandes(a)keep.pt The bulkmarcimport.pl uses replace instead of changing line, which difficults the track of the errors found in the migration. Solution: replace \r to \n -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 7609] New: Improving links to find analytics and volumes when using UseControlnumber
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '12

14 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7609 Bug #: 7609 Summary: Improving links to find analytics and volumes when using UseControlnumber Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support AssignedTo: katrin.fischer(a)bsz-bw.de ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha.sekjal(a)gmail.com There are cases when both links "Show analytics" and "Show volumes" will show up on a record. At the moment the link for both is the same, searching for all records with the 001 of the record in a $w subfield of other records. By using the bib-level index the search links can be made more precise, so "Show analytics" will only bring up analytical records while "Show volumes" will find the linked volumes and monographical records. Bib-level is the index on LDR pos. 7: - For analytics: a, b - For Volumes: everything except a, b A record showing both links is: - A serial: LDR pos. 7 = s - Part of a traced series: LDR, pos. 19 = a or a monographic series 008, Continuing resource, pos. 21 = m -- 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 13

[Bug 8382] New: It is not possible to cancel an order when receiving on a filtered page in parcel.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '12

13 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8382 Priority: P5 - low Change sponsored?: --- Bug ID: 8382 Assignee: koha-bugs(a)lists.koha-community.org Summary: It is not possible to cancel an order when receiving on a filtered page in parcel.pl Severity: blocker Classification: Unclassified OS: All Reporter: christophe.croullebois(a)biblibre.com Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha Because in parcel.pl page the filter (on the left) makes a table using jscript and a very different workflow, the "cancel" link does nothing just asking for cancelling. Principaly due to the use of the "filter" js function that call the parcel.pl page and does all the job in a separate block with a separate perl function (SearchOrder) that sends all to js, that constructs html to finally append it to table. So I have decided to rebuild entirely the filter. I have choosen to overload the function "GetPendingOrders" to enable it to accept new arguments. To test : when you are in "parcel.pl" ready to receive orders, simply select a filter on the left and on the filtered page try to cancel a line, you'll have the warning message but no more, the line will be not canceled. Instead having "Delete order" and "Delete order and catalog record", you have "cancel". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 8843] New: Cannot export bibliographic records by call number
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '12

13 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8843 Priority: P5 - low Change sponsored?: --- Bug ID: 8843 Assignee: oleonard(a)myacpl.org Summary: Cannot export bibliographic records by call number Severity: normal Classification: Unclassified OS: All Reporter: oleonard(a)myacpl.org Hardware: All Status: ASSIGNED Version: master Component: Tools Product: Koha The logic is wrong when building the query: if ($start_callnumber) { $sql_query .= " AND itemcallnumber <= ? "; push @sql_params, $start_callnumber; } if ($end_callnumber) { $sql_query .= " AND itemcallnumber >= ? "; push @sql_params, $end_callnumber; } The query must include items with call numbers *greater than* the starting call number and *less than* the ending call number, not vice versa. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 8039] New: Self Checkout/SIP: Allow authentication with userid and password
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '12

13 Dec '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8039 Priority: P5 - low Change sponsored?: --- Bug ID: 8039 Assignee: katrin.fischer(a)bsz-bw.de Summary: Self Checkout/SIP: Allow authentication with userid and password Severity: enhancement Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: SIP2 Product: Koha Currently only cardnumber + password can be used to authenticate via SIP. This is ok for self check stations where you scan the patron card, but can be a problem if you want to use SIP2 for authentication with other services. If the username does not exist as cardnumber in the system, the userid field should be checked next. -- You are receiving this mail because: You are watching all bug changes.

1 17