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

[Bug 13114] New: Shibboleth authentication patch
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '15

03 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13114 Bug ID: 13114 Summary: Shibboleth authentication patch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, dpavlin(a)rot13.org, francart(a)gmail.com, frederic(a)tamil.fr, indradg(a)gmail.com, katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, mathsabypro(a)gmail.com, matthias.meusburger(a)biblibre.com, paola.rossi(a)cineca.it, pgsengstock(a)wisc.edu, tomascohen(a)gmail.com, z.tajoli(a)cineca.it Depends on: 8446 Blocks: 12026, 12027, 12680, 12681, 12682 It appears the initial shibboleth authentication patch spams the logs with an undefined error when disabled. This is a regression and we should keep the logs quiet (unless of course debug is set). Sorry guys, patch coming soon. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 12680] New: Shibboleth adaptive config
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '15

03 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12680 Bug ID: 12680 Summary: Shibboleth adaptive config Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org I wish to enhance the shibboleth system such that you can adapt the config used depending upon some attribute returned from the identity provider. Use case: Given an academic institution, such a place may have rather differing information on record for students as opposed to staff. I've had instances where the mapping between attributes and koha fields has differed wildly between these two groups. Given the there is probably an attribute that can differentiate between the two, then we should be able to use that to load a set of mapping specific to that usergroup. Example intended implementation. <usesshibboleth>1</usesshiboleth> <shibboleth selector="affiliation" value="student"> <matchpoint>userid<matchpoint> <mapping> <userid is="uid"></userid> </mapping> </shibboleth> <shibboleth selector="affiliation" value="staff"> <matchpoint>cardnumber<matchpoint> <mapping> <cardnumber is="libraryID"></cardnumber> </mapping> </shibboleth> So, in the above example config, the intention would be for koha to look for an 'affiliation' attribute first and foremost, and then depending upon it's value (student or staff) load the corresponding configuration and continue as per normal. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 13569] New: Shibboleth example config for Packages
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '15

03 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13569 Bug ID: 13569 Summary: Shibboleth example config for Packages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, dpavlin(a)rot13.org, francart(a)gmail.com, frederic(a)tamil.fr, indradg(a)gmail.com, katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, mathsabypro(a)gmail.com, matthias.meusburger(a)biblibre.com, paola.rossi(a)cineca.it, pgsengstock(a)wisc.edu, tomascohen(a)gmail.com, z.tajoli(a)cineca.it Depends on: 8446 Blocks: 12026, 12027, 12680, 12681, 12682, 13114 Bug 8446 introduces shibboleth authentication to Koha and adds a sample config to the koha-conf.xml file along with some other pieces. However, I somehow missed adding these comments form th package installs, this bug should fix that. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 13779] New: sessionID declared twice in C4::Auth::checkauth()
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '15

03 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13779 Bug ID: 13779 Summary: sessionID declared twice in C4::Auth::checkauth() Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org "$sessionID" is declared twice in C4::Auth::checkauth(). The first time is at the start of C4::Auth::checkauth(), while the second is in the "unless ($userid || $sessionID)" block. This means that "return ( $userid, $cookie, $sessionID, $flags )", which is called within the "if ( $loggedin || $authnotrequired )" block, will never ever return the $sessionID created in the "unless ($userid || $sessionID)" block, since it's out of scope. The only time that "return ( $userid, $cookie, $sessionID, $flags )" will return "$sessionID" is if the "elsif ( $sessionID = $query->cookie("CGISESSID") )" block evaluates to true. -- In other words, "my ( $userid, $cookie, $sessionID ) = checkauth( $query, 0, { borrow => 1 }, 'opac', '');" will only have a $sessionID if the user already has the CGISESSID cookie set. This doesn't prevent checkauth() from setting the session or the cookie properly. It just means $sessionID isn't set even though it should be, because it's the value that is stored in the cookie! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4041] Address Format as a I18N/L10N system preference
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '15

02 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4041 Mirko Tietgen <mirko(a)abunchofthings.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4041] Address Format as a I18N/L10N system preference
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '15

02 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4041 Mirko Tietgen <mirko(a)abunchofthings.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #36352|0 |1 is obsolete| | --- Comment #18 from Mirko Tietgen <mirko(a)abunchofthings.net> --- Created attachment 36353 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=36353&action=edit Bug 4041 - Third step - Display address on patron's pages using the system preference This patch displays the address information in the left column of the patron's pages using the new system preference. The address is formatted in member-display-address-style-us.inc and member-display-address-style-de.inc To test: - Apply patch on top of 1st and 2nd patch - Select 'German style' in system preference 'addressformat' in I18N/L10N - Verify that the address information displays properly in the left column of all patron's pages. - Verify that the address displays properly in the main area of moremember.pl as well (Note: In right column, Alternate address /contact are not yet touched)) - Switch system preference to US style, repeat checks Signed-off-by: Mirko Tietgen <mirko(a)abunchofthings.net> -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 4041] Address Format as a I18N/L10N system preference
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '15

02 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4041 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4041] Address Format as a I18N/L10N system preference
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '15

02 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4041 --- Comment #17 from Marc Véron <veron(a)veron.ch> --- Created attachment 36352 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=36352&action=edit Bug 4041 - Third step - Display address on patron's pages using the system preference This patch displays the address information in the left column of the patron's pages using the new system preference. The address is formatted in member-display-address-style-us.inc and member-display-address-style-de.inc To test: - Apply patch on top of 1st and 2nd patch - Select 'German style' in system preference 'addressformat' in I18N/L10N - Verify that the address information displays properly in the left column of all patron's pages. - Verify that the address displays properly in the main area of moremember.pl as well (Note: In right column, Alternate address /contact are not yet touched)) - Switch system preference to US style, repeat checks -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 13759] New: git-build-snapshot misses YUI and dies of sorrow during build
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '15

02 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13759 Bug ID: 13759 Summary: git-build-snapshot misses YUI and dies of sorrow during build Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Due to a line in debian/rules, git-build-snapshot tries to delete a YUI-related path that does not exist anymore (bug 13612 I guess). Build process ends with an error. rm: cannot remove `/tmp/buildd/koha-3.19.01/debian/tmp/usr/share/koha/opac/htdocs/opac-tmpl/lib/yui': No such file or directory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 13777] New: patron lists not showing on patron search results
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '15

02 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13777 Bug ID: 13777 Summary: patron lists not showing on patron search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Created attachment 36307 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=36307&action=edit no lists I have 2 patron lists and neither shows on the list of patron results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1