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

[Bug 14405] New: Add datatable to fines table in OPAC patron account
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14405 Bug ID: 14405 Summary: Add datatable to fines table in OPAC patron account 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org It would be nice if we could sort and search the fines table on the fines tab in the patron's OPAC account. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 11622] New: Add ability to pay fees and fines from OPAC via PayPal
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11622 Bug ID: 11622 Summary: Add ability to pay fees and fines from OPAC via PayPal 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Many libraries wish to add the ability to pay fees and fines from the OPAC using PayPal. -- You are receiving this mail because: You are watching all bug changes.

1 96

[Bug 8809] New: Cascading Holds
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8809 Priority: P5 - low Change sponsored?: --- Bug ID: 8809 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Cascading Holds Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Hold requests Depends on: 7710 Product: Koha It would be nice once we have the ability to place holds on multiple items attached to one title if the patron could define which item them want first. So if they place holds all of the items attached to a TV series on DVD for example. They want to be able to say I want Disc 1 before Disc 2 and so on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 7065] New: reserves table needs a primary key
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7065 Bug #: 7065 Summary: reserves table needs a primary key Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5609 The reserves (and old_reserves) tables desperately need a primary key. reservernumber should be used for consistency sake. This will allow the possibility of multiple holds per biblio/patron combination, and a host of other improvements. This is included in bug 5872, but needs to be broken out into it's own enhancement for independent review. One cavaet: the values must be unique across the union of reserves and old_reserves. While this is easy enough to achieve in a new installation, adding the values into an existing install gets trickier. -- 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 50

[Bug 12152] New: Holds to pull report should show library and itype description instead of their codes
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12152 Bug ID: 12152 Summary: Holds to pull report should show library and itype description instead of their codes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The holds to pull report shows the library code and itype codes instead of the descriptions. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 14390] New: On renewal, the last fine is not marked as accounttype 'F' when item is checked in.
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14390 Bug ID: 14390 Summary: On renewal, the last fine is not marked as accounttype 'F' when item is checked in. Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: normal 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 When an item with a fine is renewed, the old fine is closed (i.e. accounttype is set to 'F'). A new fine is created, with an updated description. The new find is not closed when the item is checked back in. select date, amount, description, accounttype, amountoutstanding, lastincrement, timestamp from accountlines where itemnumber = 35540 and borrowernumber = 24990\G *************************** 1. row *************************** date: 2015-05-05 amount: 0.500000 description: O'Connor's annotated criminal codes plus. 05/04/2015 11:59 PM accounttype: F amountoutstanding: 0.500000 lastincrement: 0.500000 timestamp: 2015-06-08 12:42:27 *************************** 2. row *************************** date: 2015-06-08 amount: 4.500000 description: O'Connor's annotated criminal codes plus. 05/26/2015 11:59 PM accounttype: FU amountoutstanding: 4.500000 lastincrement: 0.500000 timestamp: 2015-06-08 02:02:40 2 rows in set (0.00 sec) Looking in old_issues, you can see that the item was renewed, and that date_due does match the second description... only the first accountlines entry is marked woth accounttype 'F' on return, however. select date_due, returndate, lastreneweddate, renewals, timestamp, issuedate from old_issues where itemnumber = 35540 and borrowernumber = 24990\G *************************** 1. row *************************** date_due: 2015-05-26 23:59:00 returndate: 2015-06-08 12:42:27 lastreneweddate: 2015-05-05 00:00:00 renewals: 1 timestamp: 2015-06-08 12:42:27 issuedate: 2015-04-13 09:23:20 To replicate: 1) check out an item 2) let the item go overdue and start accruing fines 3) renew the item 4) let the item go overdue again. Note that a second accountlines entry has been added 5) return the item. Note that the new fine is set with accounttype 'FU'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 8038] New: Enable network printing when UsePrintQueues is on
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8038 Priority: P5 - low Change sponsored?: --- Bug ID: 8038 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: Enable network printing when UsePrintQueues is on Severity: enhancement Classification: Unclassified OS: All Reporter: srdjan(a)catalyst.net.nz Hardware: All Status: NEW Version: unspecified Component: Circulation Product: Koha Work to be done: * If UsePrintQueues is on send slips to network printer using C4::Print::printslip() and open the print window as a fall back, rather than calling browser print() immediately How to test: * Set UsePrintQueues to No. Issue and transfer slips should be printed from the browser (pop-up), calling browser print() immediately (as it is now). * Set up a print queue on the server (sysadmin help, needs to provide queue name), add it to the printers; select the printer on the "Select Library" screen, or set it as the branch printer * Set UsePrintQueues to Yes. Issue and transfer slips should be printed from the printer queue, browser pop-up should just open and display, without calling browser print() immediately. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 8034] New: Enable server print queue selection
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8034 Priority: P5 - low Change sponsored?: --- Bug ID: 8034 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: Enable server print queue selection Severity: enhancement Classification: Unclassified OS: All Reporter: srdjan(a)catalyst.net.nz Hardware: All Status: NEW Version: unspecified Component: Circulation Product: Koha Re-enable server print queue selection that was disabled due to being disfunctional. Work to be done: * Add system preference UsePrintQueues. Print queue selection will be enabled only if UsePrintQueues is true. * Place admin/printers.pl link on the admin page. Should be visible UsePrintQueues dependent. * Add branches.default_printqueue that will be used if not set in session * Uncomment printer selection in "Set Library". Feature will be visible UsePrintQueues dependent. A follow-up bug will be created for printing using the selection. How to test: * Check that UsePrintQueues syspref is available * When UsePrintQueues is "No", check: - "Printers" link on the "Admin" page is not present - "Set Library" does not have printer selection - branch maintenance does not have default printer queue selection * When UsePrintQueues is "Yes", check: - "Printers" link on the "Admin" page is present - follow the link and add some printer queues - branch maintenance does have default printer queue selection - "Set Library" does have printer selection; select one - selected printer sticks for the session * -- You are receiving this mail because: You are watching all bug changes.

1 59

[Bug 11884] New: SlipCSS should be CSS not a file
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11884 Bug ID: 11884 Summary: SlipCSS should be CSS not a file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com SlipCSS looks for a path to a file. It would be better if it was like the UserCSS fields for Intranet and OPAC so that the average user can just enter CSS in that field instead of needing access to a web server to upload their CSS file. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 5572] New: refinements to function merge sub merge in C4::AuthoritiesMarc
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Summary: refinements to function merge sub merge in C4::AuthoritiesMarc Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Authority data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: januszop(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 Created attachment 2941 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2941 Proposed patch When merging/editing authority records bibliographic records are to be corrected. This is done by merge from C4::AuthoritiesMarc. There has been a change in this function from 30 Sept./6 Oct. (commit e9c0a11d41f107425d7f53dcc09e57e3e00ee608) [between 3.2.0 beta and 3.2.0 RC] (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5264) The original behavior in 3.0 was: when authority has been changed, then in the corresponding fields in the bibliographic records all the subfields of such fields controlled by authority will be dropped and created anew with only subfields which have a value in the authority. The new behavior is much better: in the bibliographic record only subfields which have a value in the authority_to (the new authority) will be changed. BUT what there was a subfield present (with value) in authority (and in bibliographic) and the value is now deleted form authority? It will still stay in all bibliographic, whereas it should not. Hence my proposal: subfields not active in authority framework will be preserved; subfields active in the authority framework (i.e. controlled by this authority type) should be set as in the authority record - either have the value of corresponding subfield in authority or be empty. Regards, Janusz -- 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 57