Content Access support for Features exportables

Yes, I also ran into this. Have you tried Strongarming "content_access_settings"? I'm not sure if that might help. My need for this isn't great enough to write a patch yet since I can just re-click - but it'd be nice assuming the thing I just mentioned doesn't do it.

I'm hitting the exact issue mentioned in #2.

As it stands its impossible to StrongArm a single content type's access control settings to wrap it into a feature, because the single content_access_settings variable stores info for ALL content types :/

The solution that other modules that modify content type definitions, is to add a custom variable for each content type.

Instead of a single content_access_settings we would see something like:

content_access_page
content_access_story
content_access_book
content_access_blog

(using examples of content-type machine names from standard drupal modules).

I suppose the complication comes when you turn on individual node content access. Granted, i havent looked at the node-level content access architecture, so I could be off by a lot in my assumptions here, but I wouldn't want a bunch of references to individual nids stuck into my hypothetical 'content_access_page' variable. For individual node-level access, I'd probably be using a separate table (something that works almost exactly like a cck field db table).

Yes, Regarding exporting rid vs. role name vs. role machine name, its all up in the air... and I've seen all three in different places in different types of exports. I would stick with rid since thats what the module currently uses.

Awesome Shawn! Just checking out a visual review of the patch, and it looks good, going to test it out here. and report back.

UPDATE: some feedback

This probably needs node-level handling for when a content type gets deleted, to delete the settings for that node type in the variable table.

Scenario:

* create content type 'Laundry',
* setup the content access settings....
* delete the content type,
* uninstall the content_access module,

and BAM!

* you're stuck with dirty Laundry in the variable table, because node_get_types() call in hook_uninstall() doesnt know about the content type at the time of calling.

NOTE this is not actually tested yet, just my hunch ;)

+++ content_access.module	24 Sep 2010 18:00:13 -0000
@@ -202,7 +209,60 @@ function content_access_set_settings($se
+ * Converts old-style settings to new-style settings, and vice versa.

I'm not totally sure why we would need to convert back to the old style, single-variable format once you've updated to the new style. Could you clarify this use case?

+++ content_access.module	24 Sep 2010 18:00:13 -0000
@@ -202,7 +209,60 @@ function content_access_set_settings($se
+  // Detect whether $settings is new-style or old-style
+  foreach ($types as $name => $type) {
+    if (array_key_exists('content_access_settings_'. $name, $settings)) {
+      $switch = array('new' => 'old');
+    }
+  }

Hmmm... I don't know that running through this code every time you want to get the content access settings is a good idea. I don't know how often this function is queried, but lets assume that when you're loading a view with different content types, its queried on potentially every node. At least, put a break out of the foreach once you detect if its a new style. If this logic block is really necessary, couldn't this be better done by querying the schema version, and running the update script to ensure you're at the new style? Or, you might do this with a single query to see if variable 'content_access_settings' exists instead of scanning through all the content types. If the variable doesn't exist then its new -> old?

Hope my feedback helps.

Powered by Dreditor.

Regarding your question at the bottom of #11, I'm not sure why you would need to use node_get_types() during delete. Wouldn't this work:

/**
 *  Implementation of hook_node_type().
 */
function content_access_node_type($op, $info) {
  switch ($op){
    case 'delete':
      variable_del('content_access_settings_'. $info->type);
      break;
  }
}

Can't you just use feature module's faux exportable support to set the settings without changing internas? 6.x is long stable now, so I don't like doing such drastic changes now.

I was just looking at features.api.php yesterday, as another route for implementation of this. One issue I have with going that route is that 1) it varies from the standard way that other modules who modify what could be considered to be a content-type's meta-data by breaking it out into content-type-specific variables, and 2) you'll have to know NOT to export the content_access_settings (in the variable table with strongarm), and to only export the content access settings with the custom Features export support. In this respect, requiring Features API based export to export information stored in the variables table, seems like more of an ugly hack than the current solution.

I think content-type based variables in the variable table (in the long run) is better for consistency with other modules that use the variables table to store configurations. We **could** probably hack up a Features API exportable support, which would require more code and potentially more gotchas, but i think would have the added benefits of not changing the current Content_Access API and not causing any performance hits.

However, before we go seeking in other directions, as 6.x is stable, Fago, would you even consider letting in a solution for this? a la content_access.export.inc

I think content-type based variables in the variable table (in the long run) is better for consistency with other modules that use the variables table to store configurations.

Might be, but as said in #19 - it's stable, so there won't be so drastic chances just for better consistency.

>We may be able to use that hook to be sure that strongarm does NOT export content_access_settings. If it works, that would solve your second issue, @jrguitar21.
Documenting it would be a way to go too. For sure you can do lots of stuff with strongarm that conflicts with other things.

>However, before we go seeking in other directions, as 6.x is stable, Fago, would you even consider letting in a solution for this? a la content_access.export.inc
I'd be happy to add features integration, but it should build upon the current API.

subscribing

In D7, saving "content_access_settings" partly works.

View settings are saved
Edit settings are saved for only first content type? Some yes, most no.
Delete settings untested

subscribe

subscribe

subscribe

We don't have to keep the API stable for D7, so I've implemented that for D7 + committed it. Please test.

I've attached the committed d7 patch. It turned out there are not many API changes needed, so backporting the patch to d7 could be an option.

The patch does the first part of what's required for features export: provides a per-content-type variable named using the machine name of the content type.

However, as suggested in #2 (and contrary to #5) for features compliance we must use the machine name of the role. With exported rids, we will be assigning access to indeterminate roles on target sites with the obvious accompanying security problems.

For the issue of rids, Role Export solves this problem by enabling you to give your roles a machine name, which it then generates a unique rid from based on a some kind of hash of the machine name. It makes all modules that export settings that relate to specific roles work nicely together with features and each other.

Export of settings works well, but the content_access module was not dded to my feature as a dependency. Should this automatically happen when you add one of the content access variables? Not sure, possibly not.

I posted a related handbook documentation page, Exportables and user role IDs in features.

Comment #26 patch : seem to be applied already in latest 7.x stable and latest 7.x dev

I've detected an easy to miss bug but potentially big security risk bug!.. (we'll depending on the circumstance of course) The current #26 patch found in latest stable and dev does not export edit and delete aspects of content access -- It's current iteration only exports view and view own and unfortunately neglects edit own , edit any , delete own , delete any :(

Added Screenshots showing problem as discuss in comment 32.

Logic problem located @ file: content_access.module, function content_access_get_setting_defaults
Here's why its a logic problem the purpose of this function is to get sensible default values for the settings, while the records for update,update_own,delete, delete_own are derived from the database ie. the user settings. In an effort to move this forward patch is provided as attached.

/**
 * Defines default values for settings.
 */
function content_access_get_setting_defaults($type) {
  $defaults = array();
  $defaults['view'] = $defaults['view_own'] = array(DRUPAL_ANONYMOUS_RID, DRUPAL_AUTHENTICATED_RID);
  foreach (array('update', 'delete') as $op) {
    $defaults[$op] = content_access_get_permission_access(content_access_get_permission_by_op($op, $type));
    $defaults[$op . '_own'] = content_access_get_permission_access(content_access_get_permission_by_op($op . '_own', $type));
  }
  $defaults['priority'] = 0;
  $defaults['per_node'] = FALSE;
  return $defaults;
}

This patch is an improvement because it retains the original index keys provided by patch comment #26 while fixing the logic that it only provides sensible default of empty instead of using settings from the database.

This patch is an improvement because it retains the original array index keys provided by patch comment #26 while fixing the logic that it only provides sensible default of empty instead of using settings from the database. This also removes the overrides from function content_access_admin_settings_submit of not using the form values indexed 'delete', 'delete_own', 'edit' and 'edit_own'. I've tested this patch on my local install I was able to export through features, strongarm, and role_export. I am able to update content access and see edit any, edit own, delete any, delete own are also working.

Attached Screenshot of devel variable profile of content access strong variable after patch 37 is applied.

Just making the title clearer... this has been off the radar for so long.

Please review patch proposed by comment #37

Now each content_access setting is stored in separate variable and I can export it with features and strongarm.

But after feature reverting on other Drupal installation content_access settings doesn't work. Because I need to run content_access_mass_update() to rebuild node_access_records.

Please see https://drupal.org/node/2162373

I'm not sure where we are with this. I find that individual strongarm values are available for each content type but that my content access settings are not deployed with a feature. Is this characteristic of this issue or something different?

However, as suggested in #2 (and contrary to #5) for features compliance we must use the machine name of the role. With exported rids, we will be assigning access to indeterminate roles on target sites with the obvious accompanying security problems.

Yep, that works fine with role export though - so I don't think content access should or can account for that.

-> Setting the issue back to fixed, please re-open new issues for anything left here.

Should this be fixed now?

I just tried with a fresh install of Content Access 7.x-1.2-beta2 and the permissions of the content type are not exported with the content type

Am I doing something wrong?

@vulfox, Content access stores permissions of content type in a separate variable. Use the Strongarm module to add your settings to Features. Also pay attention to mentioned issue in #41.

My bad Strongarm was not enabled fully due to Drush out ot memory.

Although this didn't seem to add that variable automatically like it did for mny others considering that content type?
By design?

Yes, you can consider it as design. You can store permissions and structure settings for the same content type in different features.