Continuing from last week, the primary focus for me this week was to focus on the permissions for users and their credentials as provided by Hawk. This involved the following:
- Allowed admins to restrict individual role’s maximum number of credentials
- Created individual permissions for creating, viewing, updating, deleting and administrating hawk credentials
- Allowed administrators to make exceptions to certain users=
Allowed admins to restrict individual role’s maximum number of credentials
For Hawk, I have added a configuration form in Admin > Configuration area which allows admins to specify a maximum limit for every role having permission to have Hawk credentials, they can specify 0 for a role to have no limit. In case an user has multiple roles with limits, maximum limit will be used for that role.
For example: There are four roles: A, B, C, D and a user has: A, C, D. A has no limit, B has 2, C has 3 and D has 5. Since the user has A which has no limits, the user will also have no limits to the number of credentials they can have.
Created individual permissions for creating, viewing, updating, deleting and administrating hawk credentials
I have split each CRUD permission into it’s own separate entity and added a separate fifth permission which grants admin access to all hawk credentials and settings. The CRUD permissions apply to individual user’s credentials. An admin can restrict a role to have credentials but not create them, allowing creations only by administrators. They can restrict them the ability to edit their revoke permissions, but add credentials and so on so forth. Hawk admins automatically get all permissions as well as ability to view and edit other’s credentials.
Allowed administrators to make exceptions to certain users
This was the most time consuming part of this week’s sprint, any user having hawk administrator permission can now add, edit or delete any other user’s hawk credentials even if that user doesn’t have the required permission and the admin can also override the limit set for the roles. For example, if a user cannot delete credentials they can request an administrator to delete one for them or if a user cannot add credentials they can do the same. The reason it took quite a bit of time was because this required a little refactoring in the way Hawk handled forms and permissions. Previously everything was assumed to be in the context of current logged in user but that required changing to the user whose profile was being viewed.
For now that’s it for the week, next week I’ll focus on further improving the module. Maybe this time I’ll finally get the chance to implement unit tests unless some other idea pops up.
Thank you for reading!