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

[Bug 9013] New: Cart in staff interface displays location pulled from Description (OPAC)
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '14

11 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9013 Priority: P5 - low Change sponsored?: --- Bug ID: 9013 Assignee: gmcharlt(a)gmail.com Summary: Cart in staff interface displays location pulled from Description (OPAC) Severity: normal Classification: Unclassified OS: All Reporter: eb(a)efdss.org Hardware: All Status: NEW Version: 3.8 Component: Architecture, internals, and plumbing Product: Koha Created attachment 13271 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13271&action=edit Example of location codes where staff and OPAC displays differ Koha allows us to display authorized values for Location in two different ways, one for the OPAC one for the staff interface. The Cart in the staff interface should display the locations that ordinarily display in the staff interface. But it seems to be pulling the location information from the Display (OPAC) line. In the example attached the staff location descriptions are much more specific, enabling staff to retrieve material from the correct storage location. In the OPAC these are marked 'storage' When staff use the Cart function to create a list of items to retrieve, they need the specific location, which is normally available in Staff interface, but unfortunately all they get is the OPAC version of this information. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 7944] New: attribute error could be clearer
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '14

11 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7944 Priority: P5 - low Change sponsored?: --- Bug ID: 7944 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: attribute error could be clearer QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Patrons Product: Koha Created attachment 9125 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9125&action=edit attribute error When you have an attribute set to unique you get an error when trying to save the patron record, but it mentions an attribute number and that number is not visible anywhere in the staff client so it's confusing the librarian entering the data what field they entered the wrong info in to. See attached (ignore the circled fields - the Driver's License is the unique field here. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 10957] New: 710$a with 710$b (subordinate unit) present shows wrong (XSLT)
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '14

11 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10957 Bug ID: 10957 Summary: 710$a with 710$b (subordinate unit) present shows wrong (XSLT) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 21494 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21494&action=edit sample If both 710$a and 710$b are present they are pasted together without punctuation or space between. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 11181] New: Koha geolocalization of OPAC users for better sort results
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '14

11 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11181 Bug ID: 11181 Summary: Koha geolocalization of OPAC users for better sort results Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org As I suggest back on 2009 (http://koha.1045719.n5.nabble.com/Geolocalization-in-Koha-td3069181.html ) it would be very nice if Koha could offer geolocation[0] (maybe using openstreetmap.org or Google Maps API). Having branches spread over a large territory make this feature very useful, making the records of the searched material more near first in the result list. Is possible to add some heuristics based on what people usually search for nearby (as Google does). There are some freely available databases[1], but also is possible to create and improve one over time, based on location established on registered and logged users, associating it with their IP address. Some extra fields for each Library should be added to database (aside code for geolocation and sorting OPAC results) like longitude and latitude on Decimal Degrees, "DD"[2], and a system preference to activate/deactivate this. [0] http://en.wikipedia.org/wiki/Geolocation [1] http://www.ipinfodb.com/ip_location_api.php [2] http://en.wikipedia.org/wiki/Decimal_degrees -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 6813] New: Acquistions - duplicate search across orders, suggestions and catalog
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '14

11 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6813 Bug #: 6813 Summary: Acquistions - duplicate search across orders, suggestions and catalog Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: savitra.sirohi(a)osslabs.biz QAContact: koha-bugs(a)lists.koha-community.org A new duplicate search tool in the acquisitions module that will allow search based on ISBN, title and/or author. Results will be across suggestions, orders and catalog. This tool will allow staff to check for duplicates before creating a new suggestion or order. -- 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 70

[Bug 9378] New: Translations don't apply?
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '14

11 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9378 Bug ID: 9378 Summary: Translations don't apply? Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com CC: frederic(a)tamil.fr Translations don't appear to apply unless more than one is selected in the I18N/L10N preferences AND the selection bar is enabled (OPAC and Intranet affected) To replicate: 1.Install a second language (I've tested with both en-GB and fr-FR) using '/misc/translate/translate install xx-XX' 2. Enable just one language other than 'en' in the I18N system preferences. 3. Refresh the OPAC or Staff Client page and the new language should take effect, but it doesn't? The only way around this that I've found is to enable multiple translations AND in the OPAC the 'allow patrons to select' option and then manually select a language. Anyone else experiencing this? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 11293] New: QueryParser date filters do not handle full dates well
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '14

10 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11293 Bug ID: 11293 Summary: QueryParser date filters do not handle full dates well Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The date filter callback for handling date filters does not handle full dates correctly. For example, * pubdate(2011-) signifies searching for records published on or after 2011 * pubdate(-1997) signifies searching for records published before or on 1997 * pubdate(1997-1999) signifies searching for records published in the applicable range However, since the hyphen is used to split elements of the range, the parsing does not currently handle full dates, e.g.: * acqdate(-2013-11-21) (items acquired on or before 2013-11-21) * acqdate(2013-01-01-2013-02-26) (items acquired during the specified range As a consequence, when QueryParser is enabled, using the acquisition date filters in the labels add-items-to-batch search form does not work. This likely accounts for the difficulty that Owen had when attempting to test the patch for bug 11222. For example, the QP query "acqdate(-2013-11-29)" gets sent to Zebra as @attrset Bib-1 @and @attr 2=4 @attr 1=Date-of-acquisition @attr 4=4 -2013-11 @attr 2=2 @attr 1=Date-of-acquisition @attr 4=4 29 when what was meant was: @attrset Bib-1 @attr 1=Date-of-acquisition @attr 4=5 @attr 2=2 2013-11-29 -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 10831] New: QueryParser requires that defaultSortField and defaultSortOrder be set to non-NULL values
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '14

10 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10831 Bug ID: 10831 Summary: QueryParser requires that defaultSortField and defaultSortOrder be set to non-NULL values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If QueryParser is enabled, the system preferences defaultSortField/defaultSortOrder (and their OPAC kin OPACdefaultSortField/OPACdefaultSortOrder) should not be set to NULL values. Otherwise, for searches where the sort order is not explicitly specified (e.g., searches made from the staff and OPAC global search box), the search can fail. This is due to several slightly questionable coding constructs collaborating in the confusion of both the user and the developer: [1] If a default sort order is not set, catalogue/search.pl and opac/opac-search.pl can end up setting the @sort_by array to (undef). This is because of the construct @sort_by = $cgi->param('sort_by'); If the sort_by CGI parameter is not passed, the result is not an empty array, it's an array containing one element whose value is undef. [2] The following code in C4::Search::parseQuery in turn uses @sort_by to add QP modifiers: if ( scalar(@sort_by) > 0 ) { my $modifier_re = '#(' . join( '|', @{ $QParser->modifiers } ) . ')'; $query =~ s/$modifier_re//g; foreach my $modifier (@sort_by) { $query .= " #$modifier"; } } If the query is "history", the modified version becomes "history #" ... which in turn results in a query that will not make sense to Zebra. One solution is to push through a DB update that extends the fix for bug 8012 to set the system preferences to sensible default values (probably relevance descending) if they're currently NULL. Note, by the way, that this means that the bug manifests itself only in databases old enough to have been created before the patch for bug 8012 was pushed. Another part of the solution, however, ought to be make the code in question a little more robust. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 11353] New: Searches with QueryParser activated are broken if an Uppercase is used in the index name
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '14

10 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11353 Bug ID: 11353 Summary: Searches with QueryParser activated are broken if an Uppercase is used in the index name Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: mathieu.saby(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org I tried to search "Title:xxxx" with Queryparser activated Result on screen of staff interface: No results match your search for 'pqf=@attr 2=102 @or @or @attr 1=1016 @attr 5=1 @attr 4=6 "Title:xxxx" @attr 9=20 @attr 2=102 @attr 5=1 @attr 4=6 "Title:xxxx" @attr 9=34 @attr 2=102 @attr 5=1 @attr 4=6 "Title:xxxx"' in Ma bibliothèque Catalog. Mathieu -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 5502] New: /cgi-bin/koha/patroncards/members-search.pl
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '14

10 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5502 Summary: /cgi-bin/koha/patroncards/members-search.pl Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Label printing AssignedTo: cnighswonger(a)foundations.edu ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When searching for patrons to add to a batch for creating patron cards, you can search by name or "category code." Category code is a text input field. It would be better for this to be a drop-down menu of existing categories. -- 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