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

[Bug 13739] New: KohaDates should display hours if they exists by default unless specified
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '15

02 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13739 Bug ID: 13739 Summary: KohaDates should display hours if they exists by default unless specified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There are many parts of Koha that are new hiding hours by default. This is rarely helpful. KohaDates should display hours by default unless the time is 23:59, in which case the hours should be not be displayed. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 11992] New: detail.pl display issue after item on hold & in transit is checked in
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '15

01 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11992 Bug ID: 11992 Summary: detail.pl display issue after item on hold & in transit is checked in Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: trivial 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 Created attachment 26540 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26540&action=edit Screenshot of detail.pl item statuses after item is checked in before confirm button When an item on hold is in transit to a library, and is checked in upon receiving it, BEFORE the confirm button is clicked, but AFTER the item is checked in, the detail.pl page shows this status for the item: "Item-level hold for [patron] for delivery at [library name] (placed date)." [attached screenshot "Screenshot of detail.pl item statuses after item is checked in before confirm button"] The item status no longer shows that the item is in transit, even though the confirm button hasn't been clicked yet. Until that confirm button is clicked, I think that status should remain, "In transit from [library a] to [library b] since [date] item-level hold for [patron] for delivery at [library b] (placed [date])". [attached screenshot of item in transit on detail-pl] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 11991] New: "Item is already waiting" message after in-transit item on hold checked in
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '15

01 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11991 Bug ID: 11991 Summary: "Item is already waiting" message after in-transit item on hold checked in Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 Created attachment 26539 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26539&action=edit Screenshot of the hold found (item is already waiting message) When an item on hold that is in transit to another branch is checked in at the library it is transiting to, the confirmation message appears with the text, "hold found (item is already waiting)..." with the confirm/print and confirm buttons. [see attachment for the message screenshot] I don't think the "item is already waiting" text is correct or useful here, as the item just arrived at the library. Is that text purposeful? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 6324] New: The upload directory (public) is not writable by the webserver.
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '15

30 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6324 Bug #: 6324 Summary: The upload directory (public) is not writable by the webserver. Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All URL: http://wiki.koha-community.org/wiki/Special:Upload OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Websites, Mailing Lists, etc AssignedTo: wizzyrea(a)gmail.com ReportedBy: mjr(a)ttllp.co.uk QAContact: koha-bugs(a)lists.koha-community.org Attempting to upload any file to the wiki produces the red error message "The upload directory (public) is not writable by the webserver." -- 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 4

[Bug 11982] New: Show local cover images in the biblio details page in the intranet.
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '15

26 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11982 Bug ID: 11982 Summary: Show local cover images in the biblio details page in the intranet. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: fcapovilla(a)live.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 26514 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26514&action=edit Show local cover image in the intranet biblio details page. This patch adds local cover images to the biblio details page in the intranet. This patch also fixes a small problem when using Amazon and Local covers at the same time : If the image is found locally, but not on Amazon, the "No cover image" was shown under the local image in the virtual shelves on the OPAC. Sponsored-by: CCSR ( http://www.ccsr.qc.ca ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60

[Bug 13914] New: The holds statistics report return random data
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '15

25 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13914 Bug ID: 13914 Summary: The holds statistics report return random data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Reports Assignee: jonathan.druart(a)biblibre.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org To reproduce: Go on Reports › Holds statistics Fill the form with: Hold status: All checked (Asked Processing Waiting Satisfied Cancelled) Hold Date From 01/01/2014 To 31/01/2014 Pickup library => empty Holding library => empty Home library => empty Row is "Hold status", Column is "Pickup library". Submit! Look at the results Restart mysql Ctrl+R to resubmit the form Look at the results Enjoy... -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 12656] New: add a notice that tells patrons when their hold was cancelled because it wasn't picked up in time
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '15

25 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12656 Bug ID: 12656 Summary: add a notice that tells patrons when their hold was cancelled because it wasn't picked up in time Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to add a notice that tells patrons when their hold was cancelled because it wasn't picked up in time - not a notice for call cancels, just the one that was done due to a late pickup. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 13855] New: Fastadd framework has 2x 100$c, missing 100$a
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '15

25 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13855 Bug ID: 13855 Summary: Fastadd framework has 2x 100$c, missing 100$a Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org Field 100$a is missing from fastadd framework, 100$c appears twice in sql file. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 13404] New: More »System information« about GRS1 vs DOM settings
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '15

25 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13404 Bug ID: 13404 Summary: More »System information« about GRS1 vs DOM settings Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: nengard(a)gmail.com Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org System information indicates missing <zebra_bib_index_mode> and <zebra_auth_index_mode> entries in koha-conf.xml. This patch - adds warnings about a possible mismatch between these settings and the actual setup - adds info about the actual setup/what values to use for <zebra_bib_index_mode> and <zebra_auth_index_mode> if they are not set. The assumption is that a path including 'zebra-*-dom.cfg' in the respective section indicates a DOM setup. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 12074] New: Filter duplicates when adding a full batch from a staged file
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '15

24 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12074 Bug ID: 12074 Summary: Filter duplicates when adding a full batch from a staged file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org Until now, when you add order for a single record from a staged batch, duplicates are checked and if found you can choose 3 different treatments : adding a new order from existing record, adding a new record nevertheless or doing nothing. But when importing the batch all in once (Import all), there's no duplicate checking. This patch aims to solve this. When adding a batch of records to a basket, duplicates are skipped and an alert is displayed with a link to them so as they could be treated individually. In the case that all batch records match an existing record, you stay on the staged batch list, a warning is also visible to tell you that nothing had been imported. The "Import all" block is not any more displayed Test plan : You need the 2 test attached files TestFile1.mrc and TestFile2.elc (TestFile1 includes only the title "Amilec ou La graine d'hommes" that is also included in TestFile2) 1) go to “Stage MARC records for import” page, upload TestFile1 and stage it (select iso 5426 encoding). 2) Manage staged record and import the batch. 3) Make sure that the new record is indexed (depending to your indexing system and test platform). 4) Go back to go to “Stage MARC records for import” page upload TestFile2 and stage it (select iso 5426 encoding). 5) Go to acquisitions module and create a new basket. 6) From your basket, in the “Add order to basket block” choose 'From a staged file'. 7) Then click File2 (‘addorder button'). 8) Go down the "Import all" block and save. 9) You are redirected to the basket page : a warning is displayed to tell you that some duplicates have been found and skipped. There's a link on the warning throughout you can go back to the list of remaining records and treat them individually if necesary. 10) Click the link : you fall upon the title of TestFile1 (of course as it's a duplicate). 11) Check that the imported records have been indexed. 11) Go down the "Import all" block and save. 12) A warning is displayed saying that no records have been imported because they all match an existing record. The “Import all” block is not any more visible. Olivier Crouzet -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28