usability of Per content node access control tab

I agree with this, and I would like to add the following suggestion for per-node access rights. Currently you first need to create a piece of content before you can access the Access Control tab.

It would be much more user friendly if the options would appear on the node add and node edit screens, below the Revision Information, Authoring Information and Publishing Options (just like the Simple Access module does). This also removes a step of possible human errors where a piece of content is first publicly created before it can have restricted access added to it.

Hmmm... need to think about this one. I agree that the labels could be much improved, but the issue is that there is difference between "View Any" and "View Own" from a functional perspective. "View Any" (which I agree should be re-labeled) allows anyone in a given role to view this particular node... "View Own" only allows someone in a role who is also the node author to view the node. The latter option can be important.

And yes, I agree that it would be better if access control could be assigned before actually creating the content. We should talk to good_man about this one and see what he thinks.

--Ben

Re labels and #3: I also found this confusing, and am worried about training my users.

How about:
"Anyone in these roles may view" or "View by anyone in these roles"
"Only author in these roles may view" or "View only by author in these roles"
etc.

The "only" could be dropped if necessary for brevity

The functionality could also be sliced by role:

More compact:

The email version of my #4 comment flattened out my nice tables. Look at #4 online for a better idea of the layout.

@dhalbert: I like a shorted version of your suggestion that would create the following labels:

* View by anyone
* View by author
* Edit by anyone
* Edit by author
* Delete by anyone
* Delete by author

I don't think we can organize by role right now because that would be a major UI change, we'd have to make the content type defaults match, and some sites could have a lot of roles. But it's an interesting idea for the future.

Let's see what good_man thinks about all of this.

--Ben

subscribing

@ Benk, then it would make more sense to put view, edit, delete as the header row, and list the roles vertically down the lefthand side, right?

[edit] I couldn't find a way to, for example, have a specific node (node 12, article) only viewable by users with a specific role, while all other nodes (article) were still visible by everyone... maybe I just missed it, but I ended up just using simple access to accomplish this. [/edit]

Subscribe. I think as a workaround to make this usable on the site I'm building I might use CSS to hide everything but the 'view any content' options, as those are all I should need on this particular site, and change the heading to 'View this '.

+1

Here is a patch that implements the labels proposed by BenK in #6. Please test and verify.

I think these labels are still a little unclear, but they are a huge improvement over what we have now. Making this form more usable is an absolute necessity if you ever plan on exposing a client to it. I'd love to hear any other suggested wordings.

-Cameron

This is a functionality question, and I'm new to this module, but I think my confusion stems from the usability issues being discussed.

I don't understand what "view own ... content" does.

BenK says

"View Own" only allows someone in a role who is also the node author to view the node.

I can't think of a scenario where a node author would not be in a role that you would select here. So why should you even have to configure this?

(the same applies for "edit own ... content" and "delete ... own content")

Node specific access controll would seem to be about this node. Not about any content of this type or my own content of this type.

Just this content.

I fully support this - module does everything I want it to but it's not very friendly for the not so technical content administrator managing the day to day nodes and permissions for each node. Great work so far - hope you can make these enhancements!

#1

It would be much more user friendly if the options would appear on the node add and node edit screens, below the Revision Information, Authoring Information and Publishing Options (just like the Simple Access module does). This also removes a step of possible human errors where a piece of content is first publicly created before it can have restricted access added to it.

Totally agree with that. Would be great!!

Is there any recommendation on how to approach adding a field to the node/add such that it offers a subset of 'roles' that can 'access' that particular node? We may have a go at a module to implement that, but suspect someone has already gone down that track

+1 this is a great module, pity that it's lacking updates...

patch in #11 works well, and is a big improvement IMO.

I'm marking this RTBC, because I think it should be committed as soon as possible.

I agree that adding content access options to the node/add form is a great idea - perhaps that should be opened as a separate feature request?

Thanks - makes sense. However, the patch still has a minor issue:

+++ b/content_access.module
@@ -570,15 +570,26 @@ function content_access_form_alter(&$form, $form_state, $form_id) {
-  );
+function _content_access_get_operations($type = NULL, $label_set = NULL) {
+  if ($label_set == 'per_node') {
+    $operations = array(
+      'view' => t('View by anyone'),
+      'view_own' => t('View by author'),
+      'update' => t('Edit by anyone'),
+      'update_own' => t('Edit by author'),
+      'delete' => t('Delete by anyone'),
+      'delete_own' => t('Delete by author'),
+    );
+  } else {
+    $operations = array(
+      'view' => t('View any @type content', array('@type' => $type)),
+      'view_own' => t('View own @type content', array('@type' => $type)),
+      'update' => t('Edit any @type content', array('@type' => $type)),
+      'update_own' => t('Edit own @type content', array('@type' => $type)),
+      'delete' => t('Delete any @type content', array('@type' => $type)),
+      'delete_own' => t('Delete own @type content', array('@type' => $type)),
+    );
+  }
   return $operations;
 }
 

The ordering of the parameters should be exchanged, such that you can leave out the type when wanting per_node labels. OR - if $type isn't optional it should not default to NULL.

Then coding style, it's
}
else {

Hi, version six lets you modify the permissions per node before you save the content , and also the page where you mark the permissions with content makes much more sense. Can't version 7 be made to work the same way as version 6 ?

All feature requests go into the most recent branch.

Added meta issue as parent.

This is a duplicate of #2119155: Very Confusing UI under per Node Access Control