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

[Bug 11633] New: Cannot use the override function AllowFineOverride on the Staff client because this stops the pay function working on the SelfCheck (SC) machines
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '14

24 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11633 Bug ID: 11633 Summary: Cannot use the override function AllowFineOverride on the Staff client because this stops the pay function working on the SelfCheck (SC) machines Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.field(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com You cannot use the override function (AllowFineOverride) on “Fines outstanding” on the Staff client because this stops the pay function working on the SelfCheck (SC) machines. The SIP2 devices share this system preference. Test Plan ========= 1) Set System Preference AllowFineOverride to "Allow". 2) On SIP2 device (e.g. 3M SelfCheck) try paying a fine. We see:- Borrower XXXXXXXXX had existing fines of 50p (2 x 25p). Attempted to borrow book YYYYYYYYYYYYY. Chose 'Pay Fines Later' and issue was allowed even with an outstanding (payable) fine. Tried to pay fines SelfCheck Machine asked for correct amount took money but then returned money stating it could not charge account and to enquire at desk. In the SIP2 response, character position 1 & 2 on the 64 response need to be set to Y for the SIP2 device to properly handle the block. 64YY Y 00020110614 ................. In Koha these are only set in two scenarios 1) If the user has expired and 2) if the user is debarred Needs a change in the Members logic the status in the ILS::Patron is setup on the basis of the return from GetMemberDetails it does not set the noissues flag if staff can override (AllowFineOverride option). In the staff client the noissuescharge is applied as part of the checkout transaction in 'CanBookBeIssued'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 11672] New: Untranslatable report areas in step 1 of Guided Reports
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '14

24 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11672 Bug ID: 11672 Summary: Untranslatable report areas in step 1 of Guided Reports 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: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr The guided reports UI shows a drop-down box with "Circulation", "Catalogue", etc. These are hard-coded in C4/Reports/Guided.pm (the @REPORT_AREA hash) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 11575] New: OPACBaseURL sometimes set by ENV variable and not system preference
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '14

20 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 Bug ID: 11575 Summary: OPACBaseURL sometimes set by ENV variable and not system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, OPACBaseURL is being set by the $ENV{'SERVER_NAME'} variable with the following code (from 2009) executed in Auth.pm's sub "get_template_and_user": OPACBaseURL => ($in->{'query'}->https() ? "https://" : "http://") . $ENV{'SERVER_NAME'} . ($ENV{'SERVER_PORT'} eq ($in->{'query'}->https() ? "443" : "80") ? '' : ":$ENV{'SERVER_PORT'}"), Basically, this checks whether or not HTTP or HTTPS was used, then uses an environmental variable to fill in the SERVER_NAME and the SERVER_PORT (if it's not 443 or 80). Unfortunately, it appears that this SERVER_NAME is set by the URL used to access Koha, rather than the ServerName provided by Apache. In many cases, this is probably fine, but it means that the OPACBaseURL can change, if you have multiple aliases or if you use an IP address to connect to Koha. Moreover, if you're using a proxy server, it seems to pick up the local domain of the proxy server and NOT the domain from the URL provided by a user. The domain from your URL will appear instead in $ENV{'HTTP_X_FORWARDED_HOST'}. I propose that we just change this variable declaration to: OPACBaseURL => ($in->{'query'}->https() ? "https://" : "http://") . C4::Context->preference("OPACBaseURL") The comments from Bug 2152 seem to indicate other times when the system preference should be used over the environmental variable as well. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 10482] New: add items limit and sort to rebuild zebra
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '14

18 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10482 Bug ID: 10482 Summary: add items limit and sort to rebuild zebra Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: fridolyn.somers(a)biblibre.com When indexing biblio records, the items are added into MARC format during database export (MARCXML or ISO2709). For some records, there is a huge number of items, mainly serials creating an item for each issue. There should be an option in rebuild_zebra.pl to limit the number of items added to record and an option to define a sort of those items. This will speed-up some indexing and avoid a known bug : when Zebra has a record with size too big for ISO2709 format this record returned as search result is broken (some items fields contains odd characters). -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 8868] New: ILS-DI: CancelHold needs to take a reserve_id
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '14

18 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8868 Priority: P5 - low Change sponsored?: --- Bug ID: 8868 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: julian.maurice(a)biblibre.com Summary: ILS-DI: CancelHold needs to take a reserve_id Severity: enhancement Classification: Unclassified OS: All Reporter: julian.maurice(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Circulation Product: Koha CancelHold takes two parameters: patron_id and item_id. If item_id is considered as an itemnumber, holds on title can't be canceled. If item_id is considered as a biblionumber, all holds on this biblionumber (for a borrower) will be canceled. So CancelHold have to consider item_id as a reserve_id. -- You are receiving this mail because: You are watching all bug changes.

1 63

[Bug 10952] New: Store anonymous search history in session
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '14

18 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10952 Bug ID: 10952 Summary: Store anonymous search history in session Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Storing search history into cookie can cause problems, due to the size limitation of 4KB. The solution here is to store search history into the CGI::Session object, so there is no size limitation -- You are receiving this mail because: You are watching all bug changes.

1 49

[Bug 7304] New: Working on funds ergonomic display and funds management by multi librarians
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '14

18 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7304 Bug #: 7304 Summary: Working on funds ergonomic display and funds management by multi librarians Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions AssignedTo: claire.hernandez(a)biblibre.com ReportedBy: claire.hernandez(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Blocks: 7163 "* aqbudgets.pl displays funds the librarians can use. There is a « show all funds » check box to access every funds. * on the fund level, you can define owner, users and/or library and then restrict access to : none of these or to the owner only or to the ower + users o to the ower + users + librarians from a specific library. We based the restriction on the library a librarian is connected to. These restrictions take effect on : acqui/acqui-home.pl acqui/booksellers.pl acqui/lateorders.pl acqui/neworderempty.pl acqui/parcel.pl admin/aqbudgets.pl admin/aqplan.pl" (BibLibre MT5557) -- 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 28

[Bug 10402] New: Add multiple contacts for vendors
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '14

18 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10402 Bug ID: 10402 Summary: Add multiple contacts for vendors Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: new feature Priority: P5 - low Component: Acquisitions Assignee: jcamins(a)cpbibliography.com Reporter: jcamins(a)cpbibliography.com Some vendors may have more than one contact. For example, a technical contact and a billing contact, or a contact for journals and a contact for monographs. Rather than require that each contact be either made into a separate vendor or recorded somewhere outside of Koha, it would be really useful of Koha had the ability to add multiple additional contacts to vendors i the acquisitions module. -- You are receiving this mail because: You are watching all bug changes.

1 119

[Bug 10883] New: OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '14

18 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10883 Bug ID: 10883 Summary: OPACAllowHoldDateInFuture can let a patron jump to the top of the holds list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a patron is allowed to add a future date for the hold using the "Hold starts on date" field, that patron can put a date in that is in the *past* which will cause them to move to the top of the holds queue ( assuming they make the past date far enough back that it is earlier than all the other hold dates ). http://screencast.com/t/s58QhaA8 -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 4861] New: Debian packaging does not include translations
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '14

17 Sep '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4861 Summary: Debian packaging does not include translations Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: lars(a)catalyst.net.nz ReportedBy: lars(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The Debian packaging of Koha does not include translations. It should include translations at least for all the languages that are 50+% translated. Since OPAC users (especially) may be wanting to use their own language, the translations should be included in the koha-common.deb package. -- 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 9