The problem at hand is that when Features are used to create content types Drupal registers Features as the content type's module which means that access control for example is being met by features_access() function.
The use-case is that while Features are great to export/import content type and other entities it may very well be required to control real access to the content type in question (remember that besides 'create', 'delete' and 'edit' there's also 'view' access which sadly there's no permission for).
Without this patch, to control access to view/load a specific content type would be only possible by:
1. patching and making changes to features_access()
2. implement logic using the node_access system which is really an overkill.
The provided patch hands the access control to whatever modules that wish to implement the required hook and in that sense it plays well with others and truly provides modular access control.
Comment | File | Size | Author |
---|---|---|---|
#13 | features--node-access.patch | 1.04 KB | malcomio |
#12 | features--node-access.patch | 1005 bytes | malcomio |
#9 | features_access.patch | 843 bytes | malcomio |
#1 | extend_node_content_type_access-1332244-1.patch | 820 bytes | lirantal |
Comments
Comment #1
lirantal CreditAttribution: lirantal commentedComment #2
lirantal CreditAttribution: lirantal commentedanyone willing to comment?
Comment #3
Grayside CreditAttribution: Grayside commentedIt is trivial to go into the hook_node_type() implementation and swap out 'features' for the current module name. It might even be possible to have that be cooked in to how the node type is exported.
No need for strange workarounds.
Comment #4
lirantal CreditAttribution: lirantal commented@Grayside
Ah? but then it requires to modify the feature code after it was created... and what will happen in successive re-create of the feature?
It's not a "strange workaround" it's called modularity and provides other modules to hook into the access system of features which is an exported module code.
Comment #5
Grayside CreditAttribution: Grayside commentedSee if hook_node_type_alter() works for you.
Comment #6
hefox CreditAttribution: hefox commentedthanks
Comment #7
mgriego CreditAttribution: mgriego commentedI'd like to re-open this. I know that this issue isn't a problem for D7, but for those of us still using D6 (and who really don't want to enable the weighty node permissions system), this is still a problem. I've worked around it with the code here, as I personally think this patch is closer to how D6 is "supposed" to work. Can this be considered for inclusion in the D6 version?
It might also be prudent to modify features_perm() to not include the standard create/delete/edit permission definitions for a node type if the owning feature implements hook_access().
Thoughts?
Comment #8
amorsent CreditAttribution: amorsent commentedI like #7
Comment #9
malcomio CreditAttribution: malcomio commentedI've changed #7 slightly for coding style - here's a patch
Comment #10
malcomio CreditAttribution: malcomio commentedComment #11
ryan_courtnage CreditAttribution: ryan_courtnage commented#7 does a fine job of solving the problem, TY. Use of hook_access() in Features-created modules is going through our QA dept right now. The patch is solid when applied against 6.x-1.2.
Edit: I should add that we've tested both with and without the use of a node access module (content_access).
Comment #12
malcomio CreditAttribution: malcomio commentedMy team did some performance testing of the patch in #9, and for low traffic sites, the patch should be fine, but we did see a performance impact.
Here's a new patch which caches the features node map
Comment #13
malcomio CreditAttribution: malcomio commentedAfter more testing, we realised that this was causing problems with creating content in certain cases, so here's a revised patch.