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

[Bug 12461] Add patron clubs feature
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |18559 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18559 [Bug 18559] Koha::Clubs - methods should not get the return type in parameter -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12461] Add patron clubs feature
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |18558 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18558 [Bug 18558] Koha::Clubs::get_enrollable explodes if no patron given -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12461] Add patron clubs feature
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |18557 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18557 [Bug 18557] Mysqlim CURRENT_DATE in Koha::Clubs::get_enrollable -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7174] Authentication rewriting
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7174 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #41536|0 |1 is obsolete| | Attachment #41537|0 |1 is obsolete| | --- Comment #24 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63255 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63255&action=ed… Bug 7174 - Authentication Rewrite - Core Depends heavily on Buugg 14540, which introduces many tests to spot regression caused by this feature. Introduces a new modular authentication system based on Exception signaling and reusable authentication components/challenges. This system is cross-framework -compatible, currently supporting Mojolicious and CGI, but adding support for any other framework is straightforward. Central idea is to provide a single authentication function to deal with all types of authentication scenarios, REST API, Cookie, Password, LDAP... Also it is important to make a system that is easy to extend and can deal with many future authentication scenarios. Currently only CGI password, LDAP and cookie login is tested. Legacy behaviour is used to deal with other types of authentication. See the attached schematic in Bugzilla for a more architectural overview. Also fixes few bugs related to anonymous_search_history The basic principle is: 1. We get an authentication request from any Web/GUI-framework, for ex CGI. 2. Request is normalized by extracting all necessary authentication data elements to a separate data structure. 3. Based on the found authentication data elements, system decides which authentication route to take. 4. Route implements all challenges needed to authenticate the request. Route returns the authenticated Koha::Borrower or an Exception if login failed. 5. The user environment/session is set/deleted based on the Route result. 6. a Koha::Borrower and the CGISESSID-cookie is returned to the calling framework in the format the framework needs. 7. Framework needs to catch possible exceptions and deal with them. Eg. login failed, no permission, under maintenance. 8. Authentication succeeds and session is set, or failure is reported to user. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14540] Move member-flags.pl to PermissionsManager to better manage permissions for testing.
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63253|0 |1 is obsolete| | --- Comment #25 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63254 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63254&action=ed… Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing. Currently there is no nice way to grant/revoke permissions for Patrons in Koha. This is a big problem when doing integration testing and when working with permissions using the future REST API. Currently we have one web-script, member-flags.pl, which deals with all permission-related things. Basically it always DELETEs all your permissions and then adds them again with some modifications. There is no internal API for creating permissions and this makes automated testing significantly harder. To create permissions for a test patron, we must decrypt the arcane way of creating koha.borrowers.flags and add user_permissions with brittle SQL-queries. This makes for very messy test scripts, and quite frankly this is hardly ever done in Koha. Also the koha.borrowers.flags-column is pretty horrible. It is 19-bit binary array where each bit tells of the patron has all permissions for the respective permission module. This is very difficult to calculate and the mechanism is hard to understand. This feature is also unnecessary, since we are always interested in having the specific permissions. We don't need to know if one Patron has all the permissions for one module. Also what happens if more subpermissions are added to the module? Existing all-permission-holders lose their all-permissions-status? Instead we could have a nice internal API to work with permissions. My patch introduces a new database structure for permissions (not necessarily better), Koha::Object implementation of the DB structure, and most importantly, a Koha::Auth::PermissionManager which is a gateway to all permissions-related actions. This feature is well tested with unit tests and PageObject integration tests. See the tests for usage examples. Especially the t/db_dependent/Members/member-flags.t I hope you like it :) SELENIUM TESTS: Now that the new permission manager enables setting permissions easily in test environments. This patch introduces more complex PageObject regressions tests. -Logged in branch regression test for Intra. -OPAC password login/logout -OPAC anonymous search history preservation. VOCABULARY: Module (permission_modules) => a module which consists of specific Permissions. Typically covers one Module in Koha. Permission (permission) => a specific Permission of a Module. Granting a Patron the permission to do something. Patron permission (borrower_permissions) => A specific Permission a specific Patron has, eg. the permission to edit bibliographic records. TEST PLAN: -2. Note the permissions a bunch of patrons has. -1. run updatedatabase.pl 0. Observe that those patrons still have the same permissions. For modules which didn't have any subpermissions, a generic subpermission is added and the patrons should have it if they had the existing module permission. Basic login: 1. Go to Koha staff client 2. Make a password login. 3. Browse to any other staff client pages to confirm that the session is active and login persists on other pages. Modify permissions: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Change your permissions. Save. 3. Go back to member-flags.pl 4. Observe that you see the same permissions you just set. Modify superlibrarian permission: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Give the superlibrarian-permission. Observe all other permissions vanishing. Save. 3. Go back to member-flags.pl 4. Observe that you see only the superlibrarian-permission active. 5. Observe that the superlibrarian permission is the only top-level permission which doesn't have any subpermissions. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14540] Move member-flags.pl to PermissionsManager to better manage permissions for testing.
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63252|0 |1 is obsolete| | --- Comment #24 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63253 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63253&action=ed… Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing. Currently there is no nice way to grant/revoke permissions for Patrons in Koha. This is a big problem when doing integration testing and when working with permissions using the future REST API. Currently we have one web-script, member-flags.pl, which deals with all permission-related things. Basically it always DELETEs all your permissions and then adds them again with some modifications. There is no internal API for creating permissions and this makes automated testing significantly harder. To create permissions for a test patron, we must decrypt the arcane way of creating koha.borrowers.flags and add user_permissions with brittle SQL-queries. This makes for very messy test scripts, and quite frankly this is hardly ever done in Koha. Also the koha.borrowers.flags-column is pretty horrible. It is 19-bit binary array where each bit tells of the patron has all permissions for the respective permission module. This is very difficult to calculate and the mechanism is hard to understand. This feature is also unnecessary, since we are always interested in having the specific permissions. We don't need to know if one Patron has all the permissions for one module. Also what happens if more subpermissions are added to the module? Existing all-permission-holders lose their all-permissions-status? Instead we could have a nice internal API to work with permissions. My patch introduces a new database structure for permissions (not necessarily better), Koha::Object implementation of the DB structure, and most importantly, a Koha::Auth::PermissionManager which is a gateway to all permissions-related actions. This feature is well tested with unit tests and PageObject integration tests. See the tests for usage examples. Especially the t/db_dependent/Members/member-flags.t I hope you like it :) SELENIUM TESTS: Now that the new permission manager enables setting permissions easily in test environments. This patch introduces more complex PageObject regressions tests. -Logged in branch regression test for Intra. -OPAC password login/logout -OPAC anonymous search history preservation. VOCABULARY: Module (permission_modules) => a module which consists of specific Permissions. Typically covers one Module in Koha. Permission (permission) => a specific Permission of a Module. Granting a Patron the permission to do something. Patron permission (borrower_permissions) => A specific Permission a specific Patron has, eg. the permission to edit bibliographic records. TEST PLAN: -2. Note the permissions a bunch of patrons has. -1. run updatedatabase.pl 0. Observe that those patrons still have the same permissions. For modules which didn't have any subpermissions, a generic subpermission is added and the patrons should have it if they had the existing module permission. Basic login: 1. Go to Koha staff client 2. Make a password login. 3. Browse to any other staff client pages to confirm that the session is active and login persists on other pages. Modify permissions: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Change your permissions. Save. 3. Go back to member-flags.pl 4. Observe that you see the same permissions you just set. Modify superlibrarian permission: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Give the superlibrarian-permission. Observe all other permissions vanishing. Save. 3. Go back to member-flags.pl 4. Observe that you see only the superlibrarian-permission active. 5. Observe that the superlibrarian permission is the only top-level permission which doesn't have any subpermissions. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14540] Move member-flags.pl to PermissionsManager to better manage permissions for testing.
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #42410|0 |1 is obsolete| | Attachment #42434|0 |1 is obsolete| | Attachment #42550|0 |1 is obsolete| | Attachment #44490|0 |1 is obsolete| | --- Comment #23 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63252 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63252&action=ed… Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing. Currently there is no nice way to grant/revoke permissions for Patrons in Koha. This is a big problem when doing integration testing and when working with permissions using the future REST API. Currently we have one web-script, member-flags.pl, which deals with all permission-related things. Basically it always DELETEs all your permissions and then adds them again with some modifications. There is no internal API for creating permissions and this makes automated testing significantly harder. To create permissions for a test patron, we must decrypt the arcane way of creating koha.borrowers.flags and add user_permissions with brittle SQL-queries. This makes for very messy test scripts, and quite frankly this is hardly ever done in Koha. Also the koha.borrowers.flags-column is pretty horrible. It is 19-bit binary array where each bit tells of the patron has all permissions for the respective permission module. This is very difficult to calculate and the mechanism is hard to understand. This feature is also unnecessary, since we are always interested in having the specific permissions. We don't need to know if one Patron has all the permissions for one module. Also what happens if more subpermissions are added to the module? Existing all-permission-holders lose their all-permissions-status? Instead we could have a nice internal API to work with permissions. My patch introduces a new database structure for permissions (not necessarily better), Koha::Object implementation of the DB structure, and most importantly, a Koha::Auth::PermissionManager which is a gateway to all permissions-related actions. This feature is well tested with unit tests and PageObject integration tests. See the tests for usage examples. Especially the t/db_dependent/Members/member-flags.t I hope you like it :) SELENIUM TESTS: Now that the new permission manager enables setting permissions easily in test environments. This patch introduces more complex PageObject regressions tests. -Logged in branch regression test for Intra. -OPAC password login/logout -OPAC anonymous search history preservation. VOCABULARY: Module (permission_modules) => a module which consists of specific Permissions. Typically covers one Module in Koha. Permission (permission) => a specific Permission of a Module. Granting a Patron the permission to do something. Patron permission (borrower_permissions) => A specific Permission a specific Patron has, eg. the permission to edit bibliographic records. TEST PLAN: -2. Note the permissions a bunch of patrons has. -1. run updatedatabase.pl 0. Observe that those patrons still have the same permissions. For modules which didn't have any subpermissions, a generic subpermission is added and the patrons should have it if they had the existing module permission. Basic login: 1. Go to Koha staff client 2. Make a password login. 3. Browse to any other staff client pages to confirm that the session is active and login persists on other pages. Modify permissions: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Change your permissions. Save. 3. Go back to member-flags.pl 4. Observe that you see the same permissions you just set. Modify superlibrarian permission: 1. Go to member-flags.pl (Home â€º Patrons â€º Set permissions) 2. Give the superlibrarian-permission. Observe all other permissions vanishing. Save. 3. Go back to member-flags.pl 4. Observe that you see only the superlibrarian-permission active. 5. Observe that the superlibrarian permission is the only top-level permission which doesn't have any subpermissions. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12461] Add patron clubs feature
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 --- Comment #84 from Kyle M Hall <kyle(a)bywatersolutions.com> --- (In reply to Jonathan Druart from comment #83) > I do not understand the $return_scalar argument you use for > get_club_enrollments and get_enrollable_clubs. Could you please explain? > > It seems useless, I suggest to remove it. It is a hack solution to an big issue with template toolkit. Basically, when calling a method from Template Toolkit that would return a Koha::Objects derived class, the result will always be returned in list context. I've tried using the scalar plugin for TT but had no luck. Even worse, if the list has only 1 element, TT will convert it to just being that element with no list context. Then, if you try to call a TT list method ( such as 'size' ), it will try to call that method on the object instead and you'll get an error! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12461] Add patron clubs feature
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12461 --- Comment #83 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- I do not understand the $return_scalar argument you use for get_club_enrollments and get_enrollable_clubs. Could you please explain? It seems useless, I suggest to remove it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14539] Introduction to castToObject(), aka. make a Koha:: Object from various input types
by bugzilla-daemon＠bugs.koha-community.org 08 May '17

08 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14539 Lari Taskula <lari.taskula(a)jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63243|0 |1 is obsolete| | --- Comment #14 from Lari Taskula <lari.taskula(a)jns.fi> --- Created attachment 63246 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63246&action=ed… Bug 14539 - Koha::Objects->cast(). Introduction to cast() (ToObject), aka. make a Koha::Object from various input types and validate. Finds a Patron-object (or any other type) from various different types of inputs. Also doubles as a validator function, dying if input is improper. USAGE: my $member = C4::Members::GetMember(borrowernumber => $borrowernumber); my $borrower = Koha::Patrons->cast($member); Currently Koha is like an archeological dig site, we have different layers of dealing with various business objects. We started with DBI and numerous ways of passing an HASH around. There is no telling if it will be a List of column => values, or a reference to HASH, or a HASH or just any of the business object's (eg. Patron's) unique identifiers (userid, cardnumber, borrowernumber). Then DBIx came to the rescue and now we are need to learn DBI and DBIx and SQL to do DB operatons in Koha. Migration to DBIx is on the way. Finally we have Koha::Object and subclasses, which include and use the DBIx, but those are not directly compatible, since Koha::Object is not a subclass of DBIx::Class making life occasionally miserable. Now we need to know 3 methods of DB accession. I am really frustrated with all of those different layers of history, and making things work nicely across all different programming patterns, I have had great success in using a casting system, where we take any value and try to make a Koha::Object-subclass out of it. So we try to cast a Scalar or a reference of Koha::Object-implementation or DBIx::ResultSet or HASH, to the desired Koha::Object-implementation. This is a nice validation/entry function in any subroutine dealing with business objects, making sure that we always have the "correct" implementation of the same business object. Unit tests included demonstrating the feature and possible pitfalls. -- You are receiving this mail because: You are watching all bug changes.

1 0