https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540 Lari Taskula <lari.taskula@jns.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #63253|0 |1 is obsolete| | --- Comment #25 from Lari Taskula <lari.taskula@jns.fi> --- Created attachment 63254 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=63254&action=edit 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.