Jump to:
| Project: | Features |
| Version: | 7.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
When exporting views using Features, I noticed that access permissions were determined solely by role ID instead of the role name (or a combination of role ID and name):
$handler->override_option('access', array(
'type' => 'role',
'role' => array(
'3' => 3,
'5' => 5,
'4' => 4,
'6' => 6,
),
));This can be a problem long-term if the feature that create these roles (prior to the view being imported) change in such a way that the role IDs shift. (Or, more commonly, if the site adds or removes roles!) I've seen this happen on features-heavy projects before, and cleaning it up can be time-consuming and confusing. The only way around this, we've found, is to run an install hook that programmatically creates roles.
Here's how a typical feature exports permissions information:
// Exported permission: access comments
$permissions[] = array(
'name' => 'access comments',
'roles' => array(
'0' => 'anonymous user',
'1' => 'authenticated user',
),
);Would it be possible to base Views' permissions on a combination of role ID and role name to help mitigate this problem. (Or, perhaps better, standardize how Views and Features export permissions?)
Comments
#1
Fixing typo.
#2
In order to do this there would need to be some string identifier for roles that does not currently exist. The same problem is true of taxonomy and vocabulary, and pretty much any other core data that is not exportable. I have thought about this, and I can't really think of a good way to do it.
In my experience, having Views permissions rely on roles, when you need to export, is fail. Instead, rely on permission strings. It has the ability to do that, and you can much more easily sync your permission strings across sites.
I'm going to leave open for a bit in case there's some conversation to be had, but I will probably "won't fix" this unless someone hands me a brilliant strategy that hasn't occurred to me.
#3
I'm embarrassed to say I didn't realize Views supports permission strings for visibility. This is obviously preferable, as one can leverage Features (if necessary) to enforce a view's access using Features' built-in permissions exporting.
However, I see one drawback: One must choose a predefined permission. If a view needed to be access by a combination of roles not serviced by an existing permission, the user must fall back to using roles.
Would it be possible to include a permissions option that creates a custom permission string for that view — say "access view my_view_name"? This would allow users to rely on permissions strings while maintaining the robustness of role-based access.
#4
Other modules or a small module can easily create custom permission strings. Also it is possible to write custom access plugins for Views that will use these strings with less user configruation. Having Views do this work would probably create a UI WTF -- the strings can't be used automatically or it will break a lot of existing sites, and if the permission strings are created and not used, that obviously will be confusing.
#5
While using a supplementary module to provide custom permission strings or access plugins for View are valid solutions, they're not easily exportable as a Features. In other words, such a module would require programming skill and isn't easily encapsulated.
I agree, though, that the UI could be confusing. Perhaps the "Permission" drop-down could include a "Custom" option and supply a text field below?
I suppose another solution would be contributing a module that allows the user to create permissions strings, though I'm not sure how well this would integrate with Features.
#6
#7
I can imagine that this is a difficult thing to fix, but I would like to add my angle to this discussion anyway.
The discussion above is mostly about using roles to handle access permissions. But there are more places where roles come into play for a view.
For instance when you try to filter a User list based on a specific role, or use the 'User' validate on an argument.
Since roles can be handled as a feature I would imagine that the needed roles are created before the view is loaded.
The views import code could then do a lookup on the role name. When a match is found it could use the named role instead of the ID from the original export.
#8
This is quite specific code. Views is written quite abstract. To handle such kind of case, it's shame to do this.
Is there already some kind of machine readable name of roles in features?
#9
In a feature a role is expressed like this:
// Exported role: foo$roles['foo'] = array(
'name' => 'foo',
);
So the original ID is not even included in a feature.
This is not really a 'machine readable' string as core currently doesn't have any facilities for this.
#10
This could be done by the features module, too.
#11
indeed, the easiest way to do this seems to alter the view inside the module file of the feature which contains the view. this would look something like this, whereas the feature is named "my_feature" and the view "my_view_name":
<?php/**
* Implements hook_views_default_views_alter().
*/
function my_feature_views_default_views_alter(&$views) {
if ($views['my_view_name']) {
$roles = _features_get_roles();
$rids = array();
foreach(array('foo', 'bar') as $role) {
$rid = $roles[$role]['rid'];
$rids[$rid] = $rid;
}
$views['my_view_name']->display['default']->display_options['filters']['rid']['value'] = array_filter($rids);
}
}
?>
#12
Indead this could be done by features automatically. No idea why they don't do this.
#13
Moving this to the features queue as they might have a more to say about this.
#14
#15
+1 -- but maybe this is actually for the ctools queue?
#16
Definitely not a CTools thing. It doesn't have any interest or visibility into in the data inside the export.
#17
Trying to make the title less.. busy.
There's various ways could be addressed, and title was suggesting just one way
#18
I have been in need of exporting roles with a machine name via views and features. I currently have a working sandbox http://drupal.org/sandbox/fatguylaughing/1297020 that will extend the User Roles section to have a machine_name field. This information gets saved into the 'role_export' table. I have also extended the views filter User: Roles to use the machine name as the key instead of the rid. This makes the views export code easy to use in a feature and not have the wrong role referenced.
However, in hopes that the features maintainers are on board with my sandbox, it would be nice to have a module_exists('role_export') statement in features during their function that exports the roles and also export the data from the role_export module.
I would be willing to help out in order to add this to features.
#19
The Role Export module should be your solution for D7 and exporting out any code base from modules that utilize the rid for the role. So for Ctools, Views, Rules, etc all these are supported without writing a new plugin each time. Please report back if this is the solution for you so this issue can be closed if possible.
#20
I posted a related handbook documentation page, Exportables and user role IDs in features.
#21
Thank you for taking the time to add this. nedjo++ :)
#22
#23
Automatically closed -- issue fixed for 2 weeks with no activity.