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

[Bug 9805] New: Lost items are un-lost if returned, but not if renewed.
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 Bug ID: 9805 Summary: Lost items are un-lost if returned, but not if renewed. Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If an item has a lost status, that status is removed when the item is returned. However, it is not removed if the item is renewed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 5501] New: why is there a 'do not notify' option?
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5501 Summary: why is there a 'do not notify' option? Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor 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 looking at the enhanced messages for patrons there is a 'do not notify' option - which is basically the same as not checking any messaging choices - so why do we need that option at all? I recommend removing it since it's confusing. -- 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 16

[Bug 7710] New: multiple holds per title
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7710 Priority: P5 - low Change sponsored?: --- Bug ID: 7710 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: multiple holds per title QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha Users shall be able to place holds on multiple items attached to a single biblio, subject to two circulation policies (configurable on the branch/item type/patron category level). One policy shall indicate the number of holds that can be placed on items with different enumchron values (different volumes), while another shall indicate the number of holds that can be placed on items with the same enumchron field (different copies). This will allow libraries to allow patrons to place holds on multiple volumes of a title, up to a reasonable limit, while limiting or preventing multiple holds on 'equivalent' copies. -- You are receiving this mail because: You are watching all bug changes.

1 135

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

[Bug 10988] New: Allow login via Google OAuth2
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10988 Bug ID: 10988 Summary: Allow login via Google OAuth2 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: vanoudt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Created attachment 21740 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=21740&action=edit oauth login helper Here at PBC, we use google apps for education to provide email for our students, and also koha for our library systems. Although we synchronise our koha accounts and google accounts, it would be much nicer for patrons to be able to simply login using OAuth2. I'm working on getting this going, basing my work on bug 9587. More details to come - but wanted to get this bug set up and start getting advice from the Koha experts. As it currently stands, the oauth2 authentication is working perfectly - on https. (Switching between the two causes issues with the cookies, as one would expect). opac/svc/oauthlogin handles all of the oauth2 magic. Opening this page will log you in. There is LOTS of room for improvement in the oauth2 login... mostly because perl is not my weapon of choice. More obviously: 1. the clientid, clientsecret need to be moved systempreferences (I've stripped ours from the attached file - these can be obtained from https://code.google.com/apis/console and then choosing "API Access" 2. Google recommends verifying and decrypting the id_token locally, which means caching some information and updating it daily. That would make things a lot faster, but does add to the complication. As was stated for the personas implementation: "The nice thing about it is, the user doesn't have to do anything, like linking their account. As long as the email address they are using... is the same as the one in Koha it will just work." -- You are receiving this mail because: You are watching all bug changes.

1 77

[Bug 11084] New: Delete biblios on Leader 05 =d
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11084 Bug ID: 11084 Summary: Delete biblios on Leader 05 =d Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: drnoe(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Position 05 of the leader in MARC 21 indicates the record's status. A lower case “d” indicates that the record is to be deleted (http://www.loc.gov/marc/authority/adleader.html) Koha should allow for deletion of bibliographic records that contain a “d” in the LEADER position 05 when by overlaying existing records. -- You are receiving this mail because: You are watching all bug changes.

1 63