Hi guys,

This is probably more of a usage question than anything else. I've created a view that I exported and stick in a module. The view includes some access limitation so only 3 roles (other than anonymous and authenticated) can view the output of the view.

Now I put that in a module so I can just install that module and get everything to work there without having to recreate the view for each website. Very practical. However, I added some access permissions based on roles 3, 4 and 5 on that website. But 3, 4 and 5 are the roles on that one website I used to create the views. When installing the views & my module on another website, that part is likely to break.

Is that a limitation?

I will write the necessary calls to get the list of roles based on what I need, but I wanted to signal the potential problem here.

  // handle access info.
  $handler->display->display_options['access']['type'] = 'role';
  $handler->display->display_options['access']['role'] = array(
    '3' => 3, // <-- this content o r variale be the name of the role
  );

Comments

dawehner’s picture

dawehner
Primary language German
commented

Perhaps this kind of support could be part of the features module. It could have a machine-readable name for each role. Then the feature module could extend the access plugin to store the machine-readable names instead of role id's.

AlexisWilke’s picture

AlexisWilke commented

Yeah. I think that the roles array should be dynamically generated instead.

Although names or IDs, it's somewhat broken since the new site may not include all the "necessary" roles. It seems that is less of a problem though because if some roles are missing, they just are not added to the list. However, an empty list would need to mean that only UID=1 can see the view...

At this point, I could switch to using a permission by adding a permission in the module. But that's not a fix for people who really need roles.

Thank you.
Alexis

shane birley’s picture

shane birley commented

This sounds like you've found a solution for your issue?

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Postponed (maintainer needs more info)

So

AlexisWilke’s picture

AlexisWilke commented
Category: task » support
Status: Closed (fixed) » Active

My solution involved programming as I had to tweak the module I was using to include an extra permission.

So my solution works for me, but I'm not so sure that everyone would like it this way. 8-)

Now the fact that Roles are not portable may just be a caveat, which is fine. However, we should to the minimum (I think) warn the user that there is something they cannot just copy & paste from one website to another without paying attention to it... That way, you don't waste a few hours trying to figure out why that view was perfectly working on site A and not on site B. Needless to say, when you discover that it doesn't work right on site B, all those supposedly private views were actually public...

Thank you.
Alexis

dawehner’s picture

dawehner
Primary language German
commented
Category: support » task
Status: Postponed (maintainer needs more info) » Active

Move to tasks.

alibama’s picture

alibama commented

If you go with running this in features you will need http://drupal.org/project/role_export to handle the roles passing between systems

alibama’s picture

alibama commented
Status: Active » Closed (fixed)

closed as per irc conversation with dawehner

Status: Active » Closed (fixed)

Correcting issue status, see #2125263: Issue status not taken from last comment during D7 migration.