August 2017 - Koha-bugs - lists.koha-community.org

[Bug 18946] New: Change language from external web fails
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '18

30 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18946 Bug ID: 18946 Summary: Change language from external web fails Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org We have identified that if you add the url to change language from one external web to koha, it doesn't work it just send you again to your current web. How to reproduce: 1. Get a multilingüal Koha like http://demo1.orex.es/cgi-bin/koha/opac-changelanguage.pl?language=en http://demo1.orex.es/cgi-bin/koha/opac-changelanguage.pl?language=es-ES 2. Copy that urls to any web page and try to link to the spanish or english version,it will keep you in the same position we suspect is opac-changelanguage.pl becuase it gets the url from the referer and then construct a wrong url becuase of the referer... If #my $url = $query->referer() || '/'; my $url = 'https://whatever/'; it works.. because we force the referer to the koha host domain -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 17785] New: oai.pl returns wrong URLs under Plack
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '18

24 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17785 Bug ID: 17785 Summary: oai.pl returns wrong URLs under Plack Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org oai.pl uses CGI's self_url Under Plack this results in an URL like: /opac/oai.pl?verb=ListRecords&resumptionToken=marcxml/100/1970-01-01T00:00:00Z/2016-12-16T23:59:59Z/ (This is the URL for the More button.) Should we adjust the mounting point and ProxyPass statements? Mount like /cgi-bin/koha/opac ? -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 18825] New: Elasticsearch - Update default authority mappings
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '18

23 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18825 Bug ID: 18825 Summary: Elasticsearch - Update default authority mappings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We currently only include a few if they authority types in the initial mappings - we need to round these out -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 17373] New: Elasticsearch - Authority mappings are not defined for UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '18

23 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17373 Bug ID: 17373 Summary: Elasticsearch - Authority mappings are not defined for UNIMARC Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org The file admin/searchengine/elasticsearch/mappings.yaml does not contain any authority mappings for UNIMARC. -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 19196] New: Add pagination helpers
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19196 Bug ID: 19196 Summary: Add pagination helpers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In order to aid UI devs work on top of the REST api, we need to provide pagination information along with the responses. It was discussed on the mailing list that following RFC5988 [1] proposal for Link headers was desirable. And also adding a header telling the total objects count would be desirable, in the lines of this link [2]. [1] https://tools.ietf.org/html/rfc5988#section-6 [2] http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#pagina… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 19160] New: CAS Single Log Out
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19160 Bug ID: 19160 Summary: CAS Single Log Out Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org CAS allows not only Single Sign On, but also Single Log out. Specification: https://apereo.github.io/cas/5.0.x/protocol/CAS-Protocol-Specification.html… 2.3.3 Single Logout The CAS Server MAY support Single Logout (SLO). SLO means that the user gets logged out not only from the CAS Server, but also from all visited CAS client applications. If SLO is supported by the CAS Server, the CAS Server MUST send a HTTP POST request containing a logout XML document (see Appendix C) to all service URLs provided to CAS during this CAS session whenever a Ticket Granting Ticket is explicitly expired by the user (e.g. during logout). CAS Clients that do not support the SLO POST requests MUST ignore these requests. SLO requests MAY also be initiated by the CAS Server upon TGT idle timeout. Koha currently doesn't support this, but it should in order to improves patron privacy and data security. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49

[Bug 17468] New: Remove koha-*-zebra scripts in favor of koha-zebra
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17468 Bug ID: 17468 Summary: Remove koha-*-zebra scripts in favor of koha-zebra Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 18851] New: use Test::DBIx::Class in 00-load.t breaks packaging
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '18

16 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18851 Bug ID: 18851 Summary: use Test::DBIx::Class in 00-load.t breaks packaging Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org Bug 18266 introduces a regression for a problem fixed in Bug 15150. Test::DBIx::Class is not mandatory because it is not available in Debian, packaging of Koha is broken because of the use in t/00-load.t. -- You are receiving this mail because: You are watching all bug changes.

1 44

[Bug 17680] New: C4::Circulation - Replace GetItemIssue with Koha::Issues
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '18

12 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17680 Bug ID: 17680 Summary: C4::Circulation - Replace GetItemIssue with Koha::Issues Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 92

[Bug 18811] New: Visibility settings inconsistent between framework and authority editor
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18811 Bug ID: 18811 Summary: Visibility settings inconsistent between framework and authority editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: Needs Signoff Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: m.de.rooy(a)rijksmuseum.nl Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, julian.maurice(a)biblibre.com, nick(a)bywatersolutions.com Blocks: 17380 Status: ASSIGNED Assignee: m.de.rooy(a)rijksmuseum.nl CC: jonathan.druart(a)bugs.koha-community.org, julian.maurice(a)biblibre.com, nick(a)bywatersolutions.com Status: Needs Signoff Patch complexity: Small patch Blocks: 17380 >From Nick Clemens on IRC: "Worth mentioning - you can't edit the 942 of an authority when creating, but it appears you can when editing, though you can't save it - confusing as end user." We should keep in mind that AddAuthority overwrites 942c when adding or modifying auth records. When adding a record: Since you choose the framework, we should not allow to change 942c here. The current behavior is fine; the field should normally be hidden via the framework. (We could even enforce it if it would not be hidden?) When modifying a record: The authorities.pl script (incorrectly) shows hidden fields when filled (which actually is weird). Since 942c is overwritten, this is useless. A closer look reveals that the visibility checks in authorities.pl do not completely correspond with the values used in auth_subfields_structure.pl. Auth_subfields_structure offers only two possibilities: 0=Show all and -5=Hide all. The code in authorities.pl now checks <=-4 or >=5 (probably remains from older code). Note that the sql install scripts initialize 942c to 8. The proposed patch adds more consistency between auth_subfields_structure.pl and authorities.pl. A non-zero value will be interpreted as hidden. IMPORTANT NOTE: This solution will remove values in hidden fields from the MARC record. Imo it is theoretically the best solution, but if we do not want to take that risk, we could also remove the two next statements at line 407 and 423 and add a specific next for 942c (enforcing to always hide it). --- Comment #1 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- In the previous comment 942c must be 942a. --- Comment #2 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 64314 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64314&action=ed… Bug 18811: Change visibility checks in authorities.pl The check is now <=-4 or >=5, but the framework uses 0 for Show all and -5 for Hide all. (Note that sql installer scripts also use 8.) When modifying an authority, the script also showed hidden fields when filled, since it did not check the hidden field but only the tab field. NOTE: The proposed solution restores consistency, but will remove hidden fields from the MARC record. Test plan: [1] Set field 942a to Show all in an authority framework. [2] Open a new record in this framework and verify that you see 942a. [3] Edit an existing record in this framework and verify again. [4] Set field 942a now to Hide all in this framework. [5] Open a new record in this framework and verify that 942a is hidden. [6] Edit an existing record in this framework and verify again. --- Comment #3 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Nick, Julian or Jonathan: Would you have any comment on the *risk* of this solution? --- Comment #4 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #3) > Nick, Julian or Jonathan: > Would you have any comment on the *risk* of this solution? This mail did not come through due to a mail problem that specific day. Second try :) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17380 [Bug 17380] Cannot edit authorities with authtypecode = default -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46