Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This is an extension to my feature request here: #789732: Add 'create' ACL operations support and can only be applied if that feature request is accepted.
I have privileged users (non-admin) who can create content types and set content-type permissions via this module.
When those users create a content type, they should be able to set who can/cannot create a node of that content type just like they can set whether that content type can be updated, viewed, and deleted.
As it stands now, if any user with said permissions creates a content type, they can never give anybody permissions to create content of that type.
Which makes no sense to me.
In the case of node-specific permissions, setting 'create' operation permissions is not provided.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | content_access-6.x-1.x-add_create_support-4.patch | 6.08 KB | thekevinday |
| #3 | content_access-6.x-1.x-add_create_support-3.patch | 8.81 KB | thekevinday |
| content_access-6.x-1.x-add_create_support-1.patch | 11.55 KB | thekevinday | |
Comments
Comment #1
NikLP CreditAttribution: NikLP commentedSubscribe.
Seems like if we're exposing nearly all the content permissions via the interface, we might as well be exposing the create content permission as well really??
Also, am I correct in saying that the content access permissions screen directly reflects any existing permissions as set up in the default "node permissions" area, and we're just able to override that here? If so, that adds more credence to the idea mentioned above.
Comment #2
thekevinday CreditAttribution: thekevinday commentedYes.
Content access and acl already reflect existing permissions set up in the default node permissions area.
This simply adds the "create permissions" to the content access interface.
As I mentioned already, there are users who need "create content-type" permissions and those users needs to be able to set who can create the new content-type as well as designate who can update, view, and delete the given content-type.
These users should not be able to access the global permissions interface and control the permissions to everything else on the system.
Also, the patch to ACL here: http://drupal.org/node/789732 is apparently not need after all.
Comment #3
thekevinday CreditAttribution: thekevinday commentedThis newer version of the patch removes the changes to rules, which was on a node-specific case.
Create access can only be specific to content-types and not the nodes of a given content-type.
Comment #5
thekevinday CreditAttribution: thekevinday commentedcontent_access_optimize_grants() seems to be for node-specific permissions where having create would not make sense. (please correct me if I am wrong).
content_access_delete_per_node_settings() also seems to be on a node-specific permissions and having create makes no sense.
Comment #7
klonos+1 !!!
subscribing...
Comment #8
thekevinday CreditAttribution: thekevinday commentedcontent_access-6.x-1.x-add_create_support-1.patch queued for re-testing.
Comment #9
thekevinday CreditAttribution: thekevinday commentedThe original patch had passed 3 weeks ago, but now fails.
I do not see anything wrong with the latest patch from #5.
Based on the test results from the original patch, the patch failing seems to be something wrong with the upstream code being tested against.
I will wait some time and re-test patch from #5.
Comment #10
janchojnacki CreditAttribution: janchojnacki commentedcontent_access-6.x-1.x-add_create_support-1.patch queued for re-testing.
Comment #11
BJ___ CreditAttribution: BJ___ commented#5: content_access-6.x-1.x-add_create_support-4.patch queued for re-testing.
Comment #11.0
BJ___ CreditAttribution: BJ___ commented...simply changed link to the issue over at the ACL project to the [#???] format ;)
Comment #12
gisle