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

[Bug 11956] New: Hold priorities not re-calculated when hold is confirmed and transferred on checkin
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '14

12 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11956 Bug ID: 11956 Summary: Hold priorities not re-calculated when hold is confirmed and transferred on checkin Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the process of testing bug 11947, discovered that if a hold is triggered as in transit to another branch and a new hold is added to the record later, the new hold gets a larger priority number than expected. Test plan to recreate: 1. Add six holds to a record, the first one needs to have a pickup location of a different branch than what you are logged in as. 2. Trigger the hold for the first patron so the item goes into transit. 3. Note that the holds priority for the record is now In Transit; 1; 2; 3; 4; 5. 4. Add a hold for another patron to the same record. 5. You expect a holds priority of 6, but it is set as 7. 6. Add a hold for another patron to the same record. 7. You expect a holds priority of 7, but it is set as 8. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 9372] New: Automatic carriage return in message_queue where content_type is html
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '14

12 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9372 Bug ID: 9372 Summary: Automatic carriage return in message_queue where content_type is html Classification: Unclassified 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: stephane.delaune(a)biblibre.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com html messages in message_queue have not <br /> instead of \n for html content types -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 4812] New: Reserves for a specific copy of a book say book is available even though it it still checked out to someone else
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '14

12 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4812 Summary: Reserves for a specific copy of a book say book is available even though it it still checked out to someone else Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: gmcharlt(a)gmail.com ReportedBy: kyle.m.hall(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When you place a reserve on a specific copy of a book a note is immediately put on the card of the person for whom the book is being reserved that says the book is available even though it is still checked out to someone else. The code is in placerequest.pl # if we have an item selectionned, and the pickup branch is the same as the holdingbranch # of the document, we force the value $rank and $found . if ($checkitem ne ''){ $rank[0] = '0' unless C4::Context->preference('ReservesNeedReturns'); my $item = $checkitem; $item = GetItem($item); if ( $item->{'holdingbranch'} eq $branch ){ $found = 'W' unless C4::Context->preference('ReservesNeedReturns'); } } This code does not bother to check to see if an item is actually on the shelf, it sets it to 'W' reguardless. -- 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 11

[Bug 9094] New: 260/264 in MARC
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '14

12 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9094 Bug ID: 9094 Summary: 260/264 in MARC Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com We have a potential issue with RDA. Publisher info is being added in the 264 in RDA sometimes, but is also in the 260. We might need to update the default XSLT to show the 260 if it's there and if not look in the 264 and show that. -- You are receiving this mail because: You are watching all bug changes.

1 3

[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 12189] New: Untranslatable page title in print slip template
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '14

11 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12189 Bug ID: 12189 Summary: Untranslatable page title in print slip template Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr printslip.pl includes this line: title => "Print Receipt for $borrowernumber", ...meaning the page title is untranslatable. -- You are receiving this mail because: You are watching all bug changes.

1 3