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

[Bug 10673] New: Message hide timeout can go out of sync in preferences.pl
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10673 Bug ID: 10673 Summary: Message hide timeout can go out of sync in preferences.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: jweaver(a)bywatersolutions.com Reporter: jweaver(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, jcamins(a)cpbibliography.com Quote from IRC: <@jcamins> pianohacker: [the save notification] won't hide, but then when you click save again, it'll hide the new one immediately after it displays. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 10442] New: Remove references to non-standard "error" class
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10442 Bug ID: 10442 Summary: Remove references to non-standard "error" class Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org There are a few references in the templates to a very old "error" class which should not be used anymore. Generally speaking '<div class="dialog alert">' should be used instead. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 10492] New: Translation problems with TT directives in po files
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10492 Bug ID: 10492 Summary: Translation problems with TT directives in po files Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: frederic(a)tamil.fr We have a few strings similar to that now appearing in the po files: [%% UNLESS hidden.defined('streetnumber') && hidden.defined('address') && hidden.defined('address2') && hidden.defined('city') && hidden.defined('state') && hidden.defined('zipcode') && hidden.defined('country') %%] Those can't be translated correctly. If you change the [%% to [% the po file will be unusable and the translation scripts will give you an error. We need to fix the underlying template problem here. http://translate.koha-community.org/de/312/translate.html#search=hidden.def… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 8620] New: Barcode searching not working correctly
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8620 Priority: P5 - low Change sponsored?: --- Bug ID: 8620 CC: jcamins(a)cpbibliography.com Assignee: gmcharlt(a)gmail.com Summary: Barcode searching not working correctly Severity: major Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: Searching Product: Koha Searching for a barcode with the barcode only as a keyword doesn't find the record. When adding the prefix bc: before the barcode, the barcode is found. DOM indexing is activated in my installation. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 10137] New: a followup of Bogue 8620 (Barcode searching not working correctly) is needed for UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10137 Bug ID: 10137 Summary: a followup of Bogue 8620 (Barcode searching not working correctly) is needed for UNIMARC Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: mathieu.saby(a)univ-rennes2.fr -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 10007] New: Totals in checkouts table
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10007 Bug ID: 10007 Summary: Totals in checkouts table Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 17302 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=17302&action=edit screenshot The checkouts table has 2 columns with prices that get totaled: - charge (that seems to be the rental fee) - price (replacement price) In my screenshot, both columns are empty, but charges are still showing a total of 434.00. I am not sure what Koha is doing here, but it doesn't seem to make sense. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 9510] New: holiday exceptions are being ignored
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9510 Bug ID: 9510 Summary: holiday exceptions are being ignored Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.8 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: melia(a)bywatersolutions.com In 3.8, holiday exceptions are still being ignored. What's happening is that when calculating the due date and skipping the days that the library is closed, the holiday exceptions are being ignored and skipped, even though the library is open. To reproduce: 1) Set a repeating holiday. Closed on Sats and Suns, for example. 2) Make an exception. We're open this Saturday (but closed all of the other ones). 3) Set usedaysmode sys pref to skip all days the library is closed. 4) Set renewalbaseperiod to use the current date. 5) Check out some items. See if due date is correctly calculated. 6) Renew some items. See if due date is correctly calculated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9569] New: IndependantBranches preference appears to override AutoLocation security feature
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9569 Bug ID: 9569 Summary: IndependantBranches preference appears to override AutoLocation security feature Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: fred.pierre(a)smfpl.org CC: gmcharlt(a)gmail.com Setting system preference "IndependantBranches" [sic] to "Don't prevent" staff from modifying objects (holds, items, patrons, etc.) belonging to other libraries appears to negate the AutoLocation ip address range, allowing any remote location to log in with proper credentials. The default or zero value appears to be "Don't Prevent" Selecting "Prevent" secures log in to our library's ip address range, but prevents checkout of some items, not sure why, as the items appear to be coded with our branch. Most items continue to checkout normally. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 8859] New: Item level holds not trapped if circ rules for item type are set to 'no holds allowed'
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8859 Priority: P5 - low Change sponsored?: --- Bug ID: 8859 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Item level holds not trapped if circ rules for item type are set to 'no holds allowed' Severity: normal Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha If the circulation rules for an item type are set to 'no holds allowed', but a librarian overrides this rule and forces an item level hold, the hold request will never be filled. When the item is checked in, Koha searches for any open hold requests that this item may fulfill, but when it sees that items with this item type don't allow holds, it skips over it. This behavior should probably be overridden for item-level holds. The relevant code is in C4::Reserves::CheckReserves. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 7825] New: Change OPACItemHolds syspref to be of type Choice, choices being "no", "yes", "force"
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '15

07 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7825 Priority: P5 - low Change sponsored?: --- Bug ID: 7825 Assignee: oleonard(a)myacpl.org Summary: Change OPACItemHolds syspref to be of type Choice, choices being "no", "yes", "force" QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: srdjan(a)catalyst.net.nz Hardware: All Status: NEW Version: master Component: OPAC Product: Koha Work to be done: * Change OPACItemHolds syspref to be of type Choice, choices being "no", "yes", "force" * opac-reserve.pl: change if (OPACItemHolds) logic to if (OPACItemHolds eq "yes") * opac-reserve.tt: - change OPACItemHolds tests to take in account new values as appropriate - if OPACItemHolds is "force" do not display "Place On" column, and automatically open "Select a specific copy" table How to test: * Set OPACItemHolds to "no". Check that OPAC holds behave as it is now (no "Place On" column, no "Select a specific copy" table, making a reserve is successful) * Set OPACItemHolds to "yes". Check that OPAC holds behave as it is now ( "Place On" column is there, "Select a specific copy" table shows when "A specific copy" is selected, making a reserve is successful) * Set OPACItemHolds to "force". Check that OPAC holds behave as follows: - no "Place On" column is present - "Select a specific copy" table is opened - making a reserve is successful -- You are receiving this mail because: You are watching all bug changes.

1 146