Permission for context module

+1 for this.

Thanks, our client needs this access too.

Hi folks, I'm setting this to by design.

It's my experience that in the vast majority of cases a separate permission isn't needed here. I do understand the request however, but there really isn't a good rule of thumb I have here, beyond 'do it in the module if there is no other way' ...and to get this behavior you don't need to hack the module as you can simply implement hook_menu_alter() when specific project needs this change.

jmiccolis, I think it's more complicated than altering hook_menu. For a project, I want to give permissions to certain roles to modify certain contexts. I can call hook_perm() to set permissions according to contexts and call hook_menu() to invoke custom access callback and arguments but one thing I cannot customize is Operations link on context listing page of context_ui module. Context administration listing form check the operations (edit, delete, etc) permissions against context_ui_task_access() which cannot be altered.

You could argue that one should override theme function (theme_context_ui_admin) but that's not a good practice since that can change.

As #5 alluded to, simply using hook_menu_alter does not produce the expected result, because theme_context_ui_admin() calls context_ui_task_access(), a custom access function that specifically denies anything but the administer site configuration permission.

One way I can see handling this is to treat context_ui_task_access() as a hook. Then, a module developer would only need to implement hook_menu_alter() and hook_task_access() without having to implement theme_context_ui_admin().

As theme_context_ui_admin() is fairly large and has a lot going on in it (and could potentially be more volatile), this seems like a better way than having module developers diff it it to figure out what's changed as context gets updated.

Attached is a stab at a patch. If this solution is accepted, it might be worth renaming the hook to something more specific, like hook_context_access(), to prevent potential namespace collisions.

I just found myself in a situation where I needed to set permission for several Roles to create/edit contexts, but I could not give them 'administer site configuration' access. The previous patches did not do the trick for me, so I read through the code and found how Context is integrating with ctools... which is how the List and Add links/pages are generated.

My patch adds a permission named 'create contexts' and then tells ctools to check for that access when rendering the admin/build/context links (except for the Settings page, which is implemented by context_ui in hook_menu and I left that as is).

I have reviewed jwhat's patch and found it acceptable for its purpose. I wish context had permission like this normally. I do not want to have to give my page builders full admin access to essentially build our content pages.

I thought of a way to make this backwards compatible by adding a checkbox to the Context admin settings page. When checked, Context will use this new 'create context' permission, otherwise it will continue using the default "administer site configuration" which is supplied by ctools.

File attached, please review.

I'd prefer a clean break, so maybe if we're going to introduce a new permission then we should add it to roles that already have the administer site configuration permission, and then we're away!

Here's a patch that will add this new 'create contexts' permission to all roles that have the 'administer site configuration' permission. This requires running update.php (or drush updb). Thanks Steven!

Thanks for the speedy work, quick review is that it looks good, but:

+++ context_ui/context_ui.install	21 Jan 2011 14:50:53 -0000
@@ -8,3 +8,37 @@
+      'query' => 'New permission added to roles: '. implode(',', $updated_roles) .'.',

Can we just tweak this message so that it says what permission we added to context. I think a site admin might wonder what Context was doing if they read this!

Can we also use the 't' function to build up the string.

Other than that, this needs testing, but I like it.

Powered by Dreditor.

I've updated the status message accordingly.

+      'query' => t("The new 'create contexts' permission has been added to the following roles: "). implode(',', $updated_roles) .'.',

Shouldn't create contexts be localized separately?

I am not sure why this is not part of the module itself.

As Drupal grows into more spaces... We need to allow granularity of permissions to allow different user roles to manage various content within the framework.

As this module stands today.. only USER1 is granted this right. USER1 is considered "god" and should really only be used for updates and high level configuration. Security practices tell us NOT to use these type of users, but rather create an admin role to use on a day to day basis.

That being said... how is this module suppose to work when the highest level of security needs to be granted.

Lastly... the reason it should be baked in to the module is... this is the practice we want module developers to follow, to have them set the precedent of how module security should operate.

In the meantime... we can all hack this great module with this great patch.. but ultimately it should be adopted into the core of the module.

Thank you for your consideration.

Should we go as far as to add permissions like:

• administer contexts
• create contexts
• edit all contexts
• edit own contexts
• delete all contexts
• delete own contexts

+1 for adding permissions to context into trunk. I have a need to hand over the context (and block) management to users who don't need to be able to manage the site as a whole.

subscribing...

@neofactor you don't currently need to be UID 1 to use context module.

@jwhat We don't have a concept of ownership of contexts, so we can't have granular permissions quite like that.

I like the idea of a permission for context, and I will be committing something along the lines of #15 in the near future.

Can anyone confirm that #15 works for them?

Someone else actually changed the 'administer site configuration' permission to 'create contexts' in another issue http://drupal.org/node/1051226.

The reason I didn't go with 'administer context' is because there is a still a Settings page which requires the 'administer site configurations' permission. I felt that 'administer' would imply the ability to change those settings as well. If everyone disagrees, I can change it.

subscribing...

I agree that we need it. I will hold off on re-rolling a patch because someone else made that change in http://drupal.org/node/1051226. If for some reason it is required to include that in my patch, someone please let me know and I will do so.

subscribing

+1 and subscribing :)

+1 - subs, but for D7.

+1 for feature inclusion in D7 and subscribing.

Needed this for a D7 site. Here is a simple implementation that creates a 'administer contexts' permission which gives access to the context ui. Doesn't have an update hook as I didn't need one. Posting here so I can include in our drush make files easily.

+1 for feature inclusion in D7 and subscribing.

Patch looks good and works as described!

patch works as described

Hello !

I see your comments about the permissions for context editor. And what about the user_dashboard / user_spaces modules integrate with context ?? (I'm on 6.x version of drupal but I tell my question here because it seems this thread is followed actively).

I have a website with user_dashboard enabled, and would like to use it as a "user homepage". I actually have a "publicdash" module to alter the menu and add some permissions / access tests to allow other users see "user_dashboard" of any user. But now my problem is that I would like to allow any user who has a dashboard to edit it's own.
The final goal is the following : user which has the "edit own dashboard context" can edit it's own dashboard page with the context editor, and access only the blocks / regions allowed in the user dashboard feature settings (blocks and regions).

What do you thing about ?
Implementing a new custom module to add new permission (edit own dashboard) and hack the context module to allow user with correct permission to see and edit the "dashboard" context ? Test in context modules if user_dashboard module exists and add my own hack into ?
I think I'm ready to do it by myself, but any suggestions on the "better way to do it" are welcome ;-)

Thanks in advance.

Re #29 - see #1050724: Context UI Revamp as this patch also includes patch in 29. thanks muschpusch for suggestions and testing.

I can confirm that the patch in #29 works as advertised. Can we please get this committed?

Without an update function, I cant consider this RTBC. As is, this has the chance of removing context access for a number of users.

+1

I need to give admin ability to administer context, but not give him site administration access! The patch works - thanks! But this needs to be part of Context so I can upgrade without overwriting the patch!

Looks like this has already been applied to 7.x-3.x, so marking as fixed. Do we need a follow up for the update hook?

Hi!
I've created a contrib module to set different permissions for all actions of context module:

http://drupal.org/project/context_permisssions

With the module, roles without "admin site configuration" permission could have access to add, edit, remove... and all other context actions.

For any users with this problem on 6.x-3.x-dev:
here is a patch for D6, similar to the patch in #29.

I know this thread is a bit old, but I tried applying this patch in #41 to the dev version and got three out of three hunks failed. need a solution so if anyone knows why, would appreciate it.

@RKopacz

Patch @41 had wrong paths. This one should work, even with the recent 6.x-3.3.