1

I have Drupal set up and some module enabled. Specifically I have the translation_overview module installed.

Now I want to give a specific role access to those pages so they can see what needs to be translated. So I gave them access to 'View translation overview assignments' but when I ask a person with this role if she can see it, she tells me she cannot.

I am an administrator, so I can obviously see everything in there. But how can I see what other roles see?

3

You can make use of Masquerade module to switch users who belongs to different roles. This will help you see what other role users see.

1

Go to admin/people/permissions and set the permissions Translate content , Administer content translations and View translation overview assigments and you must enable too this permissions for the content type:

My content type: Create new content 
My content type: Edit any content 
2

Unfortunately, permissions are a complex topic and contrib documentation (where it exists) will rarely be able to fully address all situations.

When documentation doesn't provide the info you need you have 2 options:

  1. Play around with it. Create a test account with the same role(s) as the user you're trying to solve the problem for and play with granting various permissions. Unfortunately it's not always obvious what permissions are going to have which effects as there are some permissions (like "administer content") that have far-reaching consequences.
  2. Look at the code. For page-based permissions you can typically look at the implementation of hook_menu and look at two array elements in particular: access callback and access arguments. Looking at translation_overview_menu I see several callbacks defined: To access admin/content/translation-overview-manage you can look at the access callback function and see that your user needs the manage x translation overview priorities permission, where x is any language on your site. For all of the other pages provided by the module you will notice that no access callback is defined, so they inherit the user_access value for this from their parents. So the string set in access arguments is passed directly to the user_access() function meaning that your user needs the translation overview assigments permission to see any of those pages.

If you want to learn more about how access callbacks or arguments work, read the hook_menu documentation.

This is not specific to translation_overview as it seems like a pretty simple module, but for future reference it's also worth noting that not all permissions are enforced in the menu system. Sometimes (often) code that is rendering the page itself will make calls to user_access() or node_access() or any of the other access-related functions to determine if the user has access to something and will change what's shown on the page as a result of those calls. In that case, if you don't feel too comfortable with code, you will almost certainly be reduced to using the "play around with it" method to determine the impact of various permissions.

  • Many have dreams about "how great it would be if all contributed modules would come with complete, clear and up-to-date documentation about install, admin and usage of any module" ... Only a few wake up and start contributing such documentation ... which is a perfect way to really learn how a module works. My recommendation: start digging in the issue queue of any module, and review at least any support / documentation issue. Then summarize everything you learned ... and contribute that back to the module ... – Pierre.Vriens Sep 1 '15 at 17:44
  • @Pierre.Vriens Oh, I agree. My "ideally" wasn't a value judgement on anyone. None of my modules are really documented at all :). I'm just saying that ideally...in a perfect world...it would be the case that this was in the docs. – Aaron Sep 1 '15 at 17:46
  • No problem, don't worry. Maybe you should rephrase your first phrase to something like "these are the facts: ...". That way you avoid provoking thoughts like in my comment. Just FYI: I've spend a lot of time in producing "community docu" about some of the modules I (co-)maintain (like chart, charts, and forena). True, it's "only" docu, but I think it helped quite a bit in reducing the amount of support requests (more important: "I" learned a lot from it about these modules I got involved in). – Pierre.Vriens Sep 1 '15 at 17:57
  • Fair enough, I've reworded it to make it not appear critical of module maintainers. – Aaron Sep 1 '15 at 18:00
2

In general I think people test permissions by going to the permissions page and tweaking it until it works. That's an OK process, but can have unintended consequences (you may grant more or less than you wanted).

So, first, I suggest setting up test users that you can use to log in to your site with various different combinations of permissions. That's an effective way to test out your changes.

Second, set up a test site for this kind of experiment. Doing that kind of change on a test site will help you be more confident when you tell a user that you've fixed their permissions.

Often the README.txt or project page or documentation (if it exists) will tell you what permissions to use.

My final suggestion is that the one way to be really confident that a user can access a page is to look at the code. The hook_menu of translation_overview.module and the hook_permission together shows that users with "View translation overview assigments" should be able to see the path at admin/content/translation-overview-assignments. However, there is also a permission for 'manage ' . check_plain($lang_code) . ' translation overview priorities' which is relevant. Note that there is a typo in the permission where it is missing the letter "n" in assinments.

It's possible that there is a bug in the module's permissions enforcement. The module's bug queue has a few issues that could be related.

Also, it's possible that the menu is broken and the person can access the page, but the link isn't presented. I would try visiting the page directly rather than using a link to see if access is the problem or navigation.

1

Please create a test user with the permissions.Login with the test user account and check above case so that you get to know what other users can see.

  • I didn't want to use this method, because I have a lot of roles. I did think about it though. – Noë Sep 1 '15 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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