The Domain Content module has a ton of power, but I think it might be improved if some of that power could be more specifically managed. Here's a case in point.

We have over a dozen "Zone Leaders" who each have "edit domain nodes" permission for one or more of our domains. All of them also have "set domain access" permission, so they can choose which of our domains their own content will appear on.

Since they all have "set domain access" they are also all seeing all content listed for all domains in the "Affiliated Content" forms. Thus, they can see all kinds of content listed even though they don't have the ability to edit it. If they click to edit they get access denied.

IMO, it would be good to have a permission that allows users to set domain access for their own nodes WITHOUT automatically making all content from all domains visible in the Afilliated Content pages. Ideally, they would only see nodes listed for domains where they actually have "edit domain nodes" permission.

Maybe there are two different types of "set domain access" permission? One for your own nodes, and one for other people's nodes, but "edit domain nodes" permission would also be required. On the other hand, maybe "edit domain nodes" more correctly implies what nodes should be listed in the "Affiliated Content" sections, and the "set domain access" permission is implicitly only for one's own nodes?

I dunno. I am confused. :)

Rick

CommentFileSizeAuthor
#9 dc.patch2.63 KBagentrickard

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Let me test. This may be a mistake in how permissions are handled for the Domain Content module.

DZone’s picture

DZone commented

Thanks, Ken. Let me know if there's anything you'd like me to test. You're welcome to check this out on DZone's dev site.

Rick

DZone’s picture

DZone commented

OK, I think I am getting this mentally sorted out. The essence of the problem, as I see it, is that "set domain access" should not imply "edit domain nodes" more generally. It doesn't, actually, but it gives the impression that it does.

I agree that having "set domain access" implies a need to view affiliated content for all domains, so the fact that all domains are listed is not a problem. Even though a user may only have domain access for a couple of domains, they could still assign content to ANY of the domains, so they should be able to view the content of all of them.

The "edit" link on the listings of Affiliated Content, however, is a bit of a problem. I don't think users who lack "edit domain nodes" permission for at least one of the relevant domains of a node should see an "edit" link there. The fix may be pretty easy, unless this breaks something else. In domain_content.module, we would just change lines 85-87 from:

  if ($all || $editor) {
    $check = TRUE;
  }

to

  if ($editor) {
    $check = TRUE;
  }

and I think that would do the trick. Another possibility would be NOT to assign $all on line 25 simply because a user has "set domain access" permission. I don't know what happens to admin users if you don't check for $all in line 85?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

This is one of those use-case issues that testing is all about. :-)

You can see the original design assumption: "If a user can 'set domain access,' then he or she likely has full privileges."

It may be that you do not want to give your Zone Leaders the 'set domain access' privilege at all.

There is a configuration option called 'Content Editing Forms' that tries to account for this. Do not give Zone Editors the 'set domain access' privilege. Give them the 'view domain publishing' privilege, and select the following option for 'Content Editing Forms:'

  -- Show user their publishing options 
  The node editing form is shown normally, and the user is presented a 
  list of checkboxes.  These options represent the affilaite domains that 
  the user is allowed to publish content to, according to the domains 
  assigned to their user account. 
  
  Note that if this option is selected, users with the 'view domain publshing'
  permission will also be shown a list of affilates to which the node is assigned.  
  This list shows only the affiliates that the user cannot edit.

Note also that the user is not given the ability to promote content to
'all affiliates'.  Users who need this ability should be given the 'set domain
access' permission instead.

See the README.txt, section 4.2.2 for more information.

DZone’s picture

DZone commented

Yep, this one is mildly complicated, but I still think that "set domain access" is distinct from "edit domain nodes" and that the "edit" link should not appear in the Affiliated Content views for users who may have "set domain access" but lack domain access for the specific domain.

I guess there's ambiguity insofar as a user with "set domain access" could conceivably place a node into a domain where he/she does not have edit privileges, but the scope of this is constrained to their own nodes and nodes in domains where they do have edit privileges. IMO, this seems like a good default behavior.

If I am understanding this correctly, then I would still urge that the check for edit privileges in the Affiliated Content view be made more specific, so the "edit" link only appears where the user has edit privileges. Otherwise they hit an immediate "access denied" anyway, and it seems misleading to create the appearance of an option the user doesn't actually have. It makes it look like something is broken, whereas it would all feel more normal if the "edit" link simply wasn't there to start with.

Rick

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I'm reading through my own code and documentation.

Users with the 'edit domain nodes' permission can view content for domains where
they are assigned editors.  Users with the 'set domain access' permission can 
view content for all active domains.

So, in effect, you are arguing that this is not a correct assumption. I'd love to know if other users have the same opinion.

You might try this test. Edit domain_content_menu() (lines 21-26):

  if (user_access('edit domain nodes') || user_access('administer nodes')) {
    $access = TRUE;
  }
  if (user_access('administer nodes')) {
    $all = TRUE;
  }

And domain_content_form() (lines 299-232)

  if (user_access('administer nodes')) {
    $all = TRUE;
    $message = TRUE;
  }

This should give you the behavior you describe. Then you can test if that is what you actually want.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I wonder if this patch has any effect.

http://drupal.org/files/issues/domain.module_2.patch

There is a serious bugfix here.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Assigned: Unassigned » agentrickard
Category: feature » bug
Priority: Normal » Critical

Marking as a critical bug that needs fixing before release.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Needs review
StatusFileSize
new dc.patch2.63 KB

The attached patch should provide the behavior you want.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Needs review » Closed (fixed)

Committed to HEAD.