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

[Bug 15427] New: Allow db connections using TLS
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15427 Bug ID: 15427 Summary: Allow db connections using TLS Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: chris(a)bigballofwax.co.nz QA Contact: testopia(a)bugs.koha-community.org Currently if the database server is a different machine to another we connect to it without using an encrypted connection. This will allow it to use TLS instead. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 14825] New: Accounts Rewrite Omnibus
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14825 Bug ID: 14825 Summary: Accounts Rewrite Omnibus 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.m.hall(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This bug is meant to be an omnibus to encompass the different features of the Accounts Rewrite, but to break them down into smaller more easily testable parts that do not radically alter all at once. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 7403] New: CataloguingLog warning incorrect
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7403 Bug #: 7403 Summary: CataloguingLog warning incorrect Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: nengard(a)gmail.com QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com The CataloguingLog preference says "Since this occurs whenever a book is checked in or out as well, it is not advisable to turn this on." but no one has ever been able to confirm that this is true. This warning should be removed unless someone can point to the code that makes this warning accurate. >From IRC: [09:18] <nengard> has anyone ever tested and confirmed the warning on the cataloguinglog preference? it says that its slows things down cause it tracks everytime the barcode is scanned - is that right? is the warning valid? [09:19] <jcamins> nengard: it is not correct. [09:19] <jcamins> nengard: at least, so far as I know. [09:19] <nengard> that's what i thought!!! [09:19] <nengard> and thank you jcamins [09:19] <nengard> i've asked this at least once a year for the last 4 years! -- 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 6

[Bug 15334] New: Accountlines should link to issues/old_issues using issue_id.
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15334 Bug ID: 15334 Summary: Accountlines should link to issues/old_issues using issue_id. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have perennial problems with fines due to the fact that fines don't link back to check-outs... now that we've added issue_id, we should add a linking field in accountlines, and use that wherever it's possible in the fines code (for example, fines.pl should try to link to issue_id, and only fall back to reading the description if issue_id is NULL). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 14695] New: Add ability to place multiple item holds on a given record per patron
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14695 Bug ID: 14695 Summary: Add ability to place multiple item holds on a given record per patron 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: kyle.m.hall(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently Koha only allows one hold to be placed on a given bib per patron, even it the record has multiple items. This enhancement will give Koha the ability to place a hold on at least two items on the same bibliographic record. For example, in the case of a television season DVD which has one record but many unique items. Work to be done: 1) Locate all code in Koha that checks for a patron already having a hold on a record 2) Add a new system preference to define the number of holds allowed per record 3) Create new subroutine/method to check for this 4) Implement call to new sub in areas defined in part 1 5) Ensure no code in C4::Reserves assumes that it can modify holds based on borrowernumber only This is not the first attempt at such a feature, but previous iterations are far out of date. It's time for a fresh start. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 76

[Bug 9543] New: show if holds email is subscribed on holds notification
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9543 Bug ID: 9543 Summary: show if holds email is subscribed on holds notification Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice if on the notification that pops up when checking in an item that has a hold on it it told the librarian if the patron has subscribed to hold notifications (via email, sms, or phone) so that the librarian knew not to call the patron personally or email them or whatever. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 14532] New: koha-dump shouldn't back backup Zebra indexes by default
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14532 Bug ID: 14532 Summary: koha-dump shouldn't back backup Zebra indexes by default Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz For regular use, it is not that important to save indexes every time the backup utility is run. We should add an option switch (like --indexes) so it needs to be explicitly requested. It would mean a one-line change on the cron file for people really interested. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 14464] New: Add ability to cancel waiting holds from checkin screen
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14464 Bug ID: 14464 Summary: Add ability to cancel waiting holds from checkin screen 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: jweaver(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It should be possible to manually cancel a waiting hold from the returns screen, and add the fine for an expired hold (if configured). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 7728] New: subscription endddate is copied into subscription history histendate field during renew process
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7728 Priority: P4 Change sponsored?: --- Bug ID: 7728 Assignee: koha(a)univ-lyon3.fr Summary: subscription endddate is copied into subscription history histendate field during renew process QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: koha(a)univ-lyon3.fr Hardware: All Status: NEW Version: rel_3_6 Component: Serials Product: Koha Created attachment 8240 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8240&action=edit histenddate box legend May be I missed something but even if the subscription history displays the following legend below the histenddate box: (if empty, subscription is still active) the new subscription enddate is systematically copied as histenddate during the renew process as we can see in the ReNewSubscription function (line 1332 from Serial.pm) : $query = qq| UPDATE subscriptionhistory SET histenddate=? WHERE subscriptionid=? |; $sth = $dbh->prepare($query); $sth->execute( $enddate, $subscriptionid ); -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 4850] New: CheckReserves does not respect holds circulation policies
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4850 Summary: CheckReserves does not respect holds circulation policies Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Hold requests AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Scenario: A title has two items, one of an item type that allows holds, one of a type that does not. The rules defining this are entered into smart-rules.pl, and stored in the branch_item_rules, default_branch_item_rules and default_branch_circ_rules tables in the database. Patron A checks out the item that does not allow holds (Item A). Patron B then places a title-level (next available) hold on that title. Patron B must wait until Item B is available for their hold to be filled, as per our policy. When Patron A looks at their account in the OPAC, they'll see that Item A is on hold, and cannot be renewed. Similarly, when a staff member views their record in the staff client, they will see the item as unrenewal for the same reason (pending hold). When Patron A returns Item A, a message will come up to the staff member checking in that there is a hold on this item for Patron B. This is incorrect, since Item A cannot be held, and Patron B must continue to wait until Item B is available to have their hold filled. The three tables defined above (branch_item_rules, default_branch_item_rules and default_branch_circ_rules) are not consulted anywhere in the codebase except for GetBranchItemRule in C4/Circulation.pm, which in turn is only consulted in opac-reserve.pl and reserve/request.pl. -- 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 10