May 2013 - Koha-bugs - lists.koha-community.org

[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 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 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

[Bug 6473] New: Test bug for Git-bz
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Bug #: 6473 Summary: Test bug for Git-bz Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Test Suite AssignedTo: wizzyrea(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Use this bug when testing your git-bz. :) DO YOUR WORST!! (yes, that's a challenge) -- 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 278

[Bug 10102] New: don't show empty novelist tab if no data
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '16

26 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10102 Bug ID: 10102 Summary: don't show empty novelist tab if no data Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com If you're using Novelist and have the data showing in a tab you see an empty tab for items not found in Novelist - videos specifically. The tab should be hidden if empty. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 10267] New: No error message when entering an invalid cardnumber
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10267 Bug ID: 10267 Summary: No error message when entering an invalid cardnumber Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons 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 The cardnumber field is limited to 16 in Koha. When you enter a longer cardnumber the number is cut off. When you try to change it adding the missing part, there is no error message shown and your change is just not saved. Koha should give a useful error message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 9198] New: total holds in opac doesn't stand out
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9198 Bug ID: 9198 Summary: total holds in opac doesn't stand out 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 Created attachment 13849 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13849&action=edit holds number at the bottom When you have OPACShowHoldQueueDetails set to show holds in the opac it puts the holds at the bottom of the list of holdings in regular font. It gets lost when you have a lot of items. It needs some styling and/or moving. This goes for both themes. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 8751] New: printable version of holds queue printing different pages
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8751 Priority: P5 - low Change sponsored?: --- Bug ID: 8751 Assignee: oleonard(a)myacpl.org Summary: printable version of holds queue printing different pages Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Templates Product: Koha When printing the holds queue it's giving different numbers of results based on how you have the data sorted. Using the example I have: Initial Holds Queue: 122 items Unsorted, then print preview: 13 pages Sorted by Call #, then print preview: 4 pages Sorted by Title, then print preview: 12 pages Sorted by date, then print preview: 8 pages My guess is that the CSS that controls the printable version doesn't take in to account the sorting and that's screwing with things. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 6420] New: in house use checkouts should check for circ statuses
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6420 Bug #: 6420 Summary: in house use checkouts should check for circ statuses Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com When recording in house use it appears that Koha does not check to see if the item is checked out or has a hold. That would be very useful. Regular checkout is aware of the status of the item, why not in house use? -- 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 2