Skip to Content


Shitiz Gag's Blog: [GSoC 2015: Hawk Authentication] Week 11: Improving user permission model

Planet Drupal - 4 August 2015 - 6:50am

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:

  1. Allowed admins to restrict individual role’s maximum number of credentials
  2. Created individual permissions for creating, viewing, updating, deleting and administrating hawk credentials
  3. 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!

Categories: Drupal

Chromatic: How To Manage Your Drupal Patches with 'Drush Patch File'

Planet Drupal - 4 August 2015 - 6:36am
Patching Drupal

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 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 projects[drupal][patch][] = "" ; Remove Html::resetSeenIds() call during form processing ; @see projects[drupal][patch][] = "" ; Contrib patches. ; devel ; Prefix tables in dpq() output ; @see projects[devel][patch][] = "" ; Fix incrementing invalid property in _hive() ; @see projects[devel][patch][] = "" ; entity ; entity_property_default_render_value_by_type() throws warnings on list properties ; @see projects[entity][patch][] = "" Getting Started
  1. Clone the Drush Patch File repo into your project at 'sites/all/drush'.
  2. Create a patches.make file as detailed above, preferably outside of your docroot in a 'patches' folder.
  3. 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]
Categories: Drupal

Annertech: How to Integrate your Drupal Website with MS Dynamics CRM

Planet Drupal - 4 August 2015 - 4:28am
How to Integrate your Drupal Website with MS Dynamics CRM

Recently I wrote about integrating Salesforce CRM with Drupal. Continuing in the same series, the next CRM we’re going to look at is MS Dynamics from Microsoft.

Categories: Drupal

Steam Reviews – a harsh place to be if you EVER make a mistake - by Paul Johnson Blogs - 4 August 2015 - 1:37am
Admittedly a little self-serving, but there's a real message in here about making sure you get everything right first time. Or pay the price forever...
Categories: Game Theory & Design

Virtual Reality in the Uncanny Aural Valley - by Winifred Phillips Blogs - 4 August 2015 - 1:37am
With the arrival of virtual reality, audio developers may have to wrestle with the Uncanny Valley, right alongside their visual arts counterparts. An Audio Engineering Society presentation warns of a possible obstacle to achieving convincing audio in VR.
Categories: Game Theory & Design

4 Things to Know About the Difference Between iOS and Android Mobile Gamers - by Nate Barker Blogs - 4 August 2015 - 1:37am
Ever wonder who's playing on Android and iOS? The demographics are changing and the numbers don't lie. Here's a little insight on the similarities and differences between an Apple and Android gamer.
Categories: Game Theory & Design

Did You Know? It’s possible to Blow-Off Your App Launch, Way Before Starting It - by Puneet Yamparala Blogs - 4 August 2015 - 1:37am
This post talks about the do's and dont's before publishing an app.
Categories: Game Theory & Design

Cheating at Candy Crush Saga - by Marcus Carter Blogs - 4 August 2015 - 1:37am
Often, cheating is understood as transgressive and non-playful. Thinking of it this way, and defining it just as a 'violation of rules', is an unproductive way to think about cheating and its relationship to game design.
Categories: Game Theory & Design

App Store Optimization for Game Developers - by Trevor McCalmont Blogs - 4 August 2015 - 1:37am
App Store Optimization, or ASO, is an essential marketing tactic for game developers. App Store Optimization means improving an app’s keywords, description and other attributes in order to rank higher in that marketplace’s search results.
Categories: Game Theory & Design

Achieving a &quot;walls on fire&quot; effect using simple shader changes - by Radu Muresan Blogs - 4 August 2015 - 1:37am
Step by step walk through the process of converting a static/flat art style to a more "alive" by modifying only a few lines of shader code.
Categories: Game Theory & Design

The RPGnet Newsletter: RPGnet Newsletter #15

RPGNet - 3 August 2015 - 11:00pm
After the Gen Con
Categories: Game Theory & Design

Tales from the Rocket House: More Changes that Don\'t Break the Essentials

RPGNet - 3 August 2015 - 11:00pm
Options for fighting in OD&D.
Categories: Game Theory & Design
Syndicate content

about seo