[Koha-bugs] [Bug 14540] New: Move member-flags.pl to PermissionsManager to better manage permissions for testing.

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Thu Jul 16 16:16:08 CEST 2015


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14540

            Bug ID: 14540
           Summary: Move member-flags.pl to PermissionsManager to better
                    manage permissions for testing.
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: Authentication
          Assignee: gmcharlt at gmail.com
          Reporter: olli-antti.kivilahti at jns.fi
        QA Contact: testopia at bugs.koha-community.org
                CC: dpavlin at rot13.org

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.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list