When we remember we are all mad, the mysteries disappear and life stands explained.
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!
It's only a matter of time. You encounter a bug in Drupal core or a contributed module, search the web for the issue you are encountering and more often then not, you are not the first person that has encountered the issue. You find an issue on Drupal.org and if you are really lucky, there is a viable patch associated with it. Hopefully this patch will one day make it into a release, but this won't slow you down. You apply the patch, it fixes the bug and all is well with the world. That is until it comes time to this contrib module. Maybe a different developer is performing the update, or maybe it is just you months (years?) later. You don't neccesarily remember that you previously patched this specific module and when you update it, you unintentionally overwrite the patched fix, reintroducing the bug.
To lessen the chances of this occurring, we want to be able to track all of the patches that have been applied, and ensure that they are re-applied every time the underlying code has been updated.The Old Way
In the past, we manually tracked patches in a directory at the top level of our git repository. Within this 'patches' directory, we have a folder for Drupal (core) patches and a folder for each contrib module that has had a patch applied. When a module is updated, it is up to the developer to consult this directory structure and identify any patches that may need to be reapplied. While this is technically a viable system, it is easy to see that there is at least one major flaw. It is not uncommon for a developer to simply forget to check the patches directory.Drush Patch File
Recently, we have begun to utilize Drush Patch File to improve this workflow. Drush Patch File endeavors to simply document and track what patches have been applied, and automatically reapply patches when a module has been updated.
With Drush Patch File, our legacy 'patches' folder still exists, but we replace its contents with a patches.make file similar to the one below:; Required attributes api = 2 core = 7.x ; Core patches. ; D7 Backport: theme_table() should take an optional footer variable and produce <tfoot> ; @see https://www.drupal.org/node/1892654#comment-6956588 projects[drupal][patch] = "https://www.drupal.org/files/Add_tfoot_support_to_theme_table-1892654-1.patch" ; Remove Html::resetSeenIds() call during form processing ; @see https://www.drupal.org/node/1831560#comment-7629461 projects[drupal][patch] = "https://www.drupal.org/files/d7_form_html_id_1.patch" ; Contrib patches. ; devel ; Prefix tables in dpq() output ; @see https://www.drupal.org/node/2330035#comment-9105857 projects[devel][patch] = "https://www.drupal.org/files/issues/2330035.1-dpq-prefix-tables.patch" ; Fix incrementing invalid property in _hive() ; @see https://www.drupal.org/node/2332361#comment-9118425 projects[devel][patch] = "https://www.drupal.org/files/issues/2332361.1-hive-object-corruption.patch" ; entity ; entity_property_default_render_value_by_type() throws warnings on list properties ; @see https://www.drupal.org/node/2237141#comment-8669433 projects[entity][patch] = "https://www.drupal.org/files/issues/2237141.1-list-warning.patch" Getting Started
- Clone the Drush Patch File repo into your project at 'sites/all/drush'.
- Create a patches.make file as detailed above, preferably outside of your docroot in a 'patches' folder.
Point drush to your patches.make file by adding the following line in '/sites/all/drush/drushrc.php':
$options['patch-file'] = '../patches/patches.make';
Drush Patch File's README provides detailed instructions on how to add new patches, check patch status, and apply all specified patches.The Best Part
The best part of Drush Patch File, besides managing the tracking of all of your patches, is that it will reapply your patches automatically when you update a module!drush up devel > The following indicates that the patches were successfully re-applied. Install location sites/all/modules/contrib/devel already exists. Do you want to overwrite it? (y/n): y Project devel (7.x-1.5) downloaded to sites/all/modules/contrib/devel. [success] devel patched with 2330035-1.patch. [ok]