September 2014 - Koha-bugs - lists.koha-community.org

[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

[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

[Bug 9743] New: Mandatory opac hold notes under specified conditions
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '16

11 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9743 Bug ID: 9743 Summary: Mandatory opac hold notes under specified conditions Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl CC: gmcharlt(a)gmail.com Make new opac holds notes mandatory under conditions controlled by syspref and depending on record status. To illustrate: we examine MARC21 300$a; if it contains multiple parts/volumes, but there is only one item, we ask the user to specify a part in the notes. In this case we could implement by: call this situation reason 1, add it in code and template, and specify reason 1 in the syspref. The syspref may contain a number of such reasons like: 1,2&3,4 meaning check successively 1, or 2 and 3, or 4 for new hold requests. This allows for future extension and flexible configuration. When extending this further, we should probably add a small interface on top of the syspref instead of typing 1,2&3 etc. but imo this may be sufficient to start with. This development is part of bug 9721 (umbrella report for hold changes to meet special library needs). The patch builds on bug 9722 which allows opac users to add hold notes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56

[Bug 12933] New: Add ability to print overdue slip from staff intranet
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '16

11 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12933 Bug ID: 12933 Summary: Add ability to print overdue slip from staff intranet Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some librarians would like to be able to print an overdues slip from the staff intranet. This slip would be defined as the print transport version of the ODUE slip. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 93

[Bug 7440] New: Vestiges of NoZebra should be removed
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '16

11 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7440 Bug #: 7440 Summary: Vestiges of NoZebra should be removed Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: major Priority: P3 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: jcamins(a)cpbibliography.com QAContact: ian.walls(a)bywatersolutions.com Depends on: 6227 NoZebra has been deprecated since 3.4.0. It is time to remove the vestiges of NoZebra from the code and eliminate the syspref so that people stop thinking they can use it. -- 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 34

[Bug 12366] New: Better handling of Zebra errors when searching empty indexes
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '16

11 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12366 Bug ID: 12366 Summary: Better handling of Zebra errors when searching empty indexes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, if you turn on "OpacSuppression" (i.e. Hide) or "dontmerge" (i.e. Do), Zebra will return errors, if the OpacSuppression index is empty or if the Koha-Auth-Number index is empty. You'll encounter the "dontmerge" problem if you try to merge together two authorities when there are no biblio records in the database that have already been linked to an authority. I suppose this could be an edge case, but getting a software error on the screen saying "ZOOM error 114 Unsupported Use attribute" (addinfo: Koha-Auth-Number") from diag-set 'Bib-1" isn't really that helpful. We should either add a warning on the system preference "dontmerge" (that says that you must have one biblio already attached to an authority if you don't want errors when set to "Do") or handle the error from Zebra more gracefully. Admittedly, handling the error generated by OpacSuppression is probably harder. At the moment, I think it'll say that there are no results (as Zebra will error out). I suppose that might be the best we can do...but it's still sub-optimal. Another idea is to populate OpacSuppression with a dummy record, although that's also sub-optimal. I suppose this might just be one of the downsides of using Zebra... But a warning is probably a good idea in any case for "dontmerge", although I suspect that most people probably use the "Don't" setting, or already have at least one biblio linked to an authority... -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 11324] New: "Delete All Items" fails except on "Normal Tab" 3.14
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '16

08 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11324 Bug ID: 11324 Summary: "Delete All Items" fails except on "Normal Tab" 3.14 Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: library(a)stas.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com "Delete all items" on Edit dropdown menu when viewing a biblio record will only delete records when in the "Normal" tab. When viewing another tab, clicking this command does nothing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 11700] New: C4::AuthoritiesMarc::merge enhancements/fixes
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '16

08 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11700 Bug ID: 11700 Summary: C4::AuthoritiesMarc::merge enhancements/fixes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 7419 patches contains several enhancements and fixes for subroutine C4::AuthoritiesMarc::merge. This bug is complicated to test so I will remove changes to this subroutine from bug 7419 and put it here. So maybe it will increase the chances to push these patches into master. -- You are receiving this mail because: You are watching all bug changes.

1 67