December 2012 - 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 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 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

[Bug 6934] New: New report Cash Register Statistics
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6934 Bug #: 6934 Summary: New report Cash Register Statistics Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Reports AssignedTo: gmcharlt(a)gmail.com ReportedBy: pelletiermaxime(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 5634 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5634 new report Report that ouputs cash register stats by selecting everything paid in accountlines for a specific period. -- 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 64

[Bug 5161] New: patron attributes clearing if error
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5161 Summary: patron attributes clearing if error Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Patrons 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 Estimated Hours: 0.0 When adding a patron record if you enter data in the additional attributes and you get an error about a field not being filled in the additional attributes get emptied out and you have to type them in again. they should stay filled in like the rest of the form. -- 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 9069] New: Make it possible to import MARC21 authorities from VIAF into Koha
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '16

24 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9069 Priority: P5 - low Change sponsored?: --- Bug ID: 9069 Assignee: gmcharlt(a)gmail.com Summary: Make it possible to import MARC21 authorities from VIAF into Koha Severity: enhancement Classification: Unclassified OS: All Reporter: magnus(a)enger.priv.no Hardware: All Status: NEW Version: master Component: MARC Authority data support Product: Koha Example VIAF record, HTML view: http://viaf.org/viaf/59083692/#Hamsun,_Knut,_1859-1952 Same record, MARC21: http://viaf.org/viaf/59083692/marc21.xml This can be transformed to ISO2709 with e.g.: yaz-marcdump -i marcxchange -o marc marc21.xml > myrecord.mrc I have not been able to stage and import the resulting .mrc file, and I *think* that is because the VIAF record does not have a 100 field. I think the reason for *that* is that the library/cataloguer should be able to choose the preferred name that goes into the 100 field. So maybe we need to accept authority records that lack a 100 field (so that the 100 field can be added later), or make it easy to add the 100 field as part of the import process? -- You are receiving this mail because: You are watching all bug changes.

1 3