Currently there is no nice way to grant/revoke permissions for Borrowers 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 borrower, 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 borrower 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 Borrower 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 :) 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 Borrower the permission to do something. Borrower permission (borrower_permissions) => A specific Permission a specific Borrower has, eg. the permission to edit bibliographic records. TEST PLAN: -2. Note the permissions a bunch of borrowers has. -1. run updatedatabase.pl 0. Observe that those borrowers still have the same permissions. For modules which didn't have any subpermissions, a generic subpermission is added and the borrowers 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.
Created attachment 41030 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41051 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41055 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing. Documentation improvements.
Created attachment 41056 [details] A sketch of the permissions improvements.
Created attachment 41059 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41062 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41071 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing. Fixed the updatedatabase.pl Added tests for superuser login.
Great work, Olli! And cheers to this approach to a very annoying lack! Will test as soon as possible. One suggestion, though: patching updatedatabase.pl is no longer neccesary: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13068 Documented on wiki: http://wiki.koha-community.org/wiki/Database_updates#New_workflow_since_bug_13068_has_been_pushed We're already using it, as we need multiple patches with database updates, and it greatly simplifies testing.
(In reply to Benjamin Rokseth from comment #8) > Great work, Olli! And cheers to this approach to a very annoying lack! Will > test as soon as possible. Thank you for the kind words Benjamin! Sometimes it is very hard to guess how the community will react to things :) I am also rewriting the authentication system. Or more like deprecating most of it and creating a new more modular system. There is already a lot of work in it and it works well. Integrating it to the legacy systems is really difficult, but you can see the code in Bug 7174 - Authentication rewriting. That published code is not git bz apply:able yet, but I am working on it to support the most used legacy authentication mechanisms and work really well with the new REST API :) I'll take a look at the atomicupdates!
Created attachment 41123 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41158 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41255 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41258 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41310 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41402 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 41535 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 42390 [details] [review] Bug 14540 - PermissionManager - Followup fix sample_patrons.sql
Created attachment 42410 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager to better manage permissions for testing.
Created attachment 42432 [details] [review] Bug 14540 - Followup regression test for bad login
Created attachment 42434 [details] [review] Bug 14540 - Followup regression test for bad login
Created attachment 42550 [details] [review] Bug 14540 - PermissionManager - Hotfix check_api_auth, remove flags.
Created attachment 44490 [details] [review] Bug 14540 - Move member-flags.pl to PermissionsManager. Recover from changed userid mid-session.
Created attachment 63252 [details] [review] 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.
Created attachment 63253 [details] [review] 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.
Created attachment 63254 [details] [review] 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.