This is as much a philosophical as a technical question. We are using EE 2.11.1 for this project.

We have relatively complex front-end permission requirements. They are all need-to-know permissions, i.e. views not edits. I have researched the topic and found the hooblong and hookan add-ons. However, based on my dev experience, I believe I can create a custom system for our permissions requirements. But as I am new to EE, I am not sure if I should. So this is mostly a question of 'best practice' and if you can see issues down the road.

Permission Requirements

Member Groups:

  • Super Admins
  • Editor Type A
  • Editor Type B, etc.
  • B2B User
  • B2C User

The difference between B2B and B2C user can be nicley solved through EE's internal template permissions. However, the B2B Users will have a very granular and mix-and-match permissions requirement:

  • View Country 1
  • View country 2, etc.
  • Application View 1
  • Application View 2, etc.

There are nine countries and the applications list will be extended post-publication. A B2B User can have a very individual combination of these permissions, i.e. it's not feasible to solve this through member groups. (Additionally there will be permissions synchronization from our CRM system.)

User Setup

Using Solspace's User Add-On, we are implementing a system where a user is always associated (as Associated Author) with a company channel entry. The permissions illustrated above will always be company-wide, i.e. all users associated with a company will have the same permissions.

Considered Approach

The solution that I am currently considering is:

  • Store permissions as fields in company channel entry
  • On member login use member_member_login_single hook to load the user's asociated company profile including permissions (will have to do this anyway, as the company profile holds information which will be needed to connect to 3rd party tools)
  • In the template, check permissions in the company profile and display content accordingly. (Often it will be a show / don't show case.)

So, is this a terrible approach? Are there any issues experienced EE devs see on the horizon? Are there preformance issues to be considered? Any other input I need to consider?

2 Answers 2


Yes, your plan is a reasonable one. The only change I'd make is to use sessions_end rather than member_member_login_single. The latter only fires upon login, but presumably you'll need to know the member's permissions throughout their session. The former fires on every page load.

Inside of that hook you could simply set some global variables based on the permissions data you fetched for the logged-in member.

ee()->config->_global_vars['can_access_usa'] = true;
ee()->config->_global_vars['can_access_canada'] = false;

(As a very simple example.)

Alternately, skip the extension altogether and write a module with a tag pair which uses conditionals to process your permissions.

$vars = array(
    'can_access_canada' => false,
    'can_access_usa' => true
return ee()->TMPL->parse_variables_row(ee()->TMPL->tagdata, $vars);

Then in your template you can use:

    {if can_access_canada}
        // Do stuff
  • Oh, I like that last suggestion. Regarding member_member_login_single vs sessions_end: I was thinking about populating php session variables on log in, this way I wouldn't have to 'reload' the permissions on each load. Is that not a good approach in EE? I do like that everything could be handled within the EE framework, it would make the code much more manageable for any potential dev who is not me.
    – EXODev
    Commented May 26, 2016 at 2:36
  • Another question: if I set the permissions as _global_vars; won't I run into parse order issues when I am trying to perform a conditional on them?
    – EXODev
    Commented May 26, 2016 at 3:22
  • You could use PHP sessions to store the data, sure, but you'd also have to hook into the member_member_logout hook to destroy your sessions. (EE doesn't use native PHP sessions - it uses a cookie and a database table.) Re: the global vars - when set in this manner they are "early-parsed" global variables, so you shouldn't run into any parse order issues. Commented May 26, 2016 at 14:15
  • I have successfully designed a basic feasibility test for the Permissions Module approach suggested by you, Derek. There are some questions open on how to deal with scaleability but it works fine in the front-end and fulfills all requirements. Thanks for the input.
    – EXODev
    Commented May 27, 2016 at 9:38

Ultimately, "best practice" will come down to balancing the following factors: - Your channel structure, the containers for all data. - Your group structure which controls access - Your template structure which gives, as you have stated, a certain amount of intersection between groups and data - Finding some way to limit the number of different access/data combinations - A way to overcome the limitation of One Member, One Group

Mixing and matching access using pure native EE is, as you have realised, not feasible, and Derek has given excellent advice on how to get around that limitation within the boundaries of the information you have provided.

However, you are no longer in "Native EE" territory whatever you do.

What is not entirely clear to me, is how dynamic are your access-control needs? Assuming that each user belongs to only one company at a time, your access control combinations come down to Company/Country/Application. I can't tell how many combinations you have to consider without knowing how many companies and applications as well as countries, but it really does not matter unless access will be static once set up, which seems unlikely.

Once you get over a few (ten to twenty) combinations, the job of visualising the security consequences of making any change becomes an impossible challenge, so you need a way to lock in how your access control works so that it cannot be bypassed by combinations that may not have been anticipated during the design phase.

I have wrestled with this extensively for a number of clients with similarly dynamic "need-to-know" content access needs, which is why I developed HooKan and HooBlong. While they in no way make your data and access-control design job any easier, they do simplify the post-deployment admin job.

View HooBlong Features

  • Thanks for the insight, John. At the moment we have 13 individual permissions which potentially can be combined in any which permutation. Which, if my math is right, runs into the billions of potential combinations. ;) I am pretty much done with a feasibility test of Derek's solution. The front-end functionality will work just fine, but I am currently a bit concerned about the back-end functionality, i.e. adding a new permission as a channel field and ensuring (in a simple fashion), that it will get included in the module.
    – EXODev
    Commented May 27, 2016 at 2:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.