First off, thanks for your work on this -- this module does a great job controlling access rights, and installed with no issues at all --

I'm running this on a site with the latest 5.x dev tarball (from approx May 15th), together with ACL 1.4 --

When setting rights for individual users on a node, to give a user the right to update a node, you currently need to assign a user both "view" and "update" rights -- it seems to make more sense to have "update" rights include "view" rights, as there probably won't be any situations where a user would be able to update a node without actually seeing it --

From a usability perspective, this also saves a step for end users -- as the module now works, node editors need to be given both "view" and "update" rights. Having "update" include "view" rights as well would make the module easier to use.

Thanks,

Bill

Comments

fago’s picture

fago
Primary language German
Location Vienna
commented
Status: Active » Closed (won't fix)

hm, one doesn't need necessarily view access. updating a node works also without view access.
Furthermore I don't see a problem for also checking the view checkbox.

bonobo’s picture

bonobo commented
Component: Code » User interface
Category: bug » feature
Status: Closed (won't fix) » Active

RFC here --

As the module currently works, User A creates a node.

User A gives User B the right to see the node, and gives user C the right to update the node.

User A saves access controls.

So, User B comes along and views the node. Great -- all is hunky-dory.

User C, however, who has upgrade rights over the node, cannot actually see the node they can update. The only way they can actually edit this node is if they navigate to node/x/edit -- this assumes, of course, that they *know* the node exists, and have the url to it, and know that they can edit the node by navigating to node/nid/edit --

RE: "Furthermore I don't see a problem for also checking the view checkbox." -- this is not a checkbox issue -- this issue arises when User A wants to give additional users rights over nodes -- ie, for each user with rights, User A needs to select the user who has rights -- if a user wants to give one user rights to view a node, and two additional users rights to update the node, as your module currently works, they need to make 5 selections -- one to give the first user rights to the node, and two more to give the updaters rights to view the node, and then two more to give the updaters rights to update the node.

By including "view" rights with "update" rights, you would eliminate two steps for the end user.

If this is something you don't want to look at, or don't have the time to look at, that's totally fine -- to state the obvious, your time is your time, and I'm not saying you *need* to fix this -- this is, however, a usability issue that makes some very useful functionality more difficult to access --

Toward that end, I'm changing the component to UI, the category to a feature request, and marking the status as active.

Cheers,

Bill

fago’s picture

fago
Primary language German
Location Vienna
commented

ah, you are talking of the ACL integration right?
Ok, I agree with you that adding the same user two times isn't really user friendly.

So what would you suggest?

* view access ACL
* view & update ACL
* view & update & delete ACL - better call it "Grant full permission" or such?

Perhaps it would make sense, if once could configure this per content type - e.g. we could allow the user to enable/disable each of these ACLs.

bonobo’s picture

bonobo commented

Hello,

Two things I'd recommend --

First, I'd make the access grants cumulative -- "view" just gives view rights; "update" gives view and update rights; "delete" gives view, update, and delete -- these access rights will cover the vast majority of use cases, as there aren't many users who will be entrusted with delete privileges who wouldn't also have the ability to view or edit the content they will be deleting.

Second, in the "view" option, I'd throw in an option for "all users" -- this provides an intuitive choice for when someone wants to make a piece of content visible to all site members, but only editable by a couple --

Thanks again for your time in taking a look at the UI on this -- this module (along with your ACL upgrade) provides some much-needed functionality.

Cheers,

Bill

fago’s picture

fago
Primary language German
Location Vienna
commented
Status: Active » Postponed

sry, as it seems I don't have the time for this :/ But perhaps anyone else want jump in?

mizengineer’s picture

mizengineer commented
Status: Postponed » Active

Just want to say that this has worked perfectly so far. Only shortcoming is that for user-defined access control, the author is not automatically included as being able to view/update/delete file! I had to include the author username as one of those who also has above rights. I can live with this though. Thank you for a very useful and critical tool! (Simple Access, Node Access Control, Node Privacy ByRole did not work for me!)

gettysburger’s picture

gettysburger commented
Version: 5.x-1.0 » 6.x-1.x-dev
Category: feature » support

Maybe I'm just thick, but I can't find the page where I set rights for individual users on a node. Thanks.

Stephen

gettysburger’s picture

gettysburger commented

I figured this out myself. I needed to install ACL. All is well with the world. Thanks.

Cheers,
Stephen

gaxunil’s picture

gaxunil commented
Title: With Content Access module, clarify the relationship b/w view and update grants » Content Access module not preventing content view
Version: 6.x-1.x-dev » 5.x-1.5
Component: User interface » Miscellaneous

Hi,
I'm taking over a Drupal site that is using Drupal 5.10.
I've installed ACL 1.6 and Content Access 1.5.
It's running PHP 5.2.6 on IIS 6.0
Also have Menu Per Role module installed to hide certain menus based on role.
There are other modules installed, but these are the only ones I can see that would control content access.

The issue I'm having is that I'm able to view content that I believe I shouldn't be able to.
Here's what I've done
-created content type "executive content"
-created role "executive" that can view content of type "executive content" (via the Access Control tab on the content type)
-created role "executive publisher" that can create/update "executive content"
-other roles are not allowed to view "executive content"
-created some content (a page) with content type "executive content"

Now if I login with a user that does NOT have the role "executive content" assigned, I can still type in the URL of the "executive content" page and the content is viewable. The behavior I would expect would be an access denied page. I've tried removing all roles from the user and can still see the "executive content" page. I've tried rebuilding the permissions and running the update script. I'm not sure how to tell why/what may be giving the go ahead to display this content given that the role and Content Access should be preventing view access.

I'm not sure if I'm missing something or what. Any suggestions or help?
Thanks!

good_man’s picture

good_man commented
Status: Active » Closed (won't fix)

Closing it as 5.x is not supported anymore.