After created a domain with the domain_access module i create some content using the user/1 account for that domain.
Now i tried to edit these content using another user (an affiliated one) and in some nodes i have rights to edit it, and in some nodes i haven´t. I noted that recent nodes (created before the user registered), always give the rights to edit. But old nodes doesn't

I install drupal 6.10 and domain access module 6x-2.0-rc6

Mi primary domain is http://comunidad.cav.sld.cu -is a private net, not reachable from outside
others domains http://gescon.cav.sld.cu -some old nodes with rights some with not
http:// www.socuenf.cav.sld.cu -Never can edit the old nodes.

I wonder if is a configuration issue.

I defined the user´s role with "edit domain nodes" permission and in the profile in the "Domain access" settings: i checked the domains, but still doesn't work.

I created a new content_type named socuenf
In the permission page i even assigned in the "node permission" settings

create socuenf content
delete any socuenf content
delete own socuenf content
edit any socuenf content
edit own socuenf content

for the user's role

But the user can edit old nodes, nothing yet.

Excuse my English please

CommentFileSizeAuthor
#6 access dening.gif70.17 KBneopulse

Comments

agentrickard’s picture

Category: bug » support

Turn on the debugging output and see what it tells you about the nodes.

neopulse’s picture

I already did it, and i can read something like:

Assigned domains

* GesCon

Source domain: GesCon

But i can still edit the node.
I even try to reach the page trough the url, ex: http://gescon.cav.sld.cu/node/8/edit, thinking in a theme trouble but it appear "access denied" message

agentrickard’s picture

I misunderstood the issue. You have given the user too many permissions.

The editing permissions are, well, permissive. If any of the access rules gives you access, then you get access.

As a result, if the user has the 'edit any socuenf content' permission, node access rules are never even invoked.

See section 3.3 of README.txt for a detailed explanation.

neopulse’s picture

I'm afraid I still misunderstand how the domain rights works, I read it a thousand of times, but I'm still uncertain

I erase old roles and create new one, just to start from scratch. Gave them (the roles) those permissions

assign domain editors
delete domain nodes
edit domain nodes
set domain access
view domain publishing

Then assign this role to one user, and set in the user profile page in the Domain access settings: making this user affiliated to the domain in issue.

is that right??

I install devel module in i found something odd.

If I get into the node as an administrator the "Access permissions by user" panel show me; for the user before mentioned, rights to see, edit, and erase the node. But when I enabled the panel for that user it show rights just for see, and erase the node, but not for edit, even the panel say the same rights for the user/1.

Thats really odd.

Remember that this happens for old nodes, I mean nodes created before the the user created..
New nodes are ok

PD: Excuse my English please

agentrickard’s picture

User 1 and users with 'administer nodes' are not subject to node access rules.

Everything else seems to be configured correctly.

Devel Node Access will give you a detailed explanation of how Domain Access is behaving.

It is possible that the old nodes are not assigned to the proper domain. Devel can show you that. You can also use Domain Content to change the access rights using a batch operation.

neopulse’s picture

StatusFileSize
new70.17 KB

This is driving my crazy

The information provided by the "Domain access information" panel and the "Devel Node Access" are the same for a editable node and a not editable one.

Here are a screen shot

agentrickard’s picture

Then the difference comes down to the user looking at the page.

If the user looking at this page is assigned to domain 3 _and_ has the 'edit domain nodes' permission, then he or she should be able to edit the node. With the following exceptions:

1) The node uses an input filter not accessible by the user. (Security fail)

2) The user cannot 'access content'. (Permission fail)

3) You are using a custom (non-CCK) node type that implements its own permissions. (Configuration fail)

4) The node is unpublished. (Security fail)

5) You have other node access modules interfering with Domain Access. (Configuration fail)

The first 4 elements are all inherent limitations of Drupal's Node Access system. See http://api.drupal.org/api/function/node_access/6

neopulse’s picture

Status: Active » Closed (fixed)

Yesssssssss
You were right, you are the best, man. Thank you very, very much.

The trouble was with the first exception you mentioned.

The node uses an input filter not accessible by the user. (Security fail)

I defined 2 input formats, one "full html" for (or to) the administrator, and another "filtered html" format for (or to) registered users, to avoid, you know, javascript, malformed html and css and so. I apply the same format to affiliated users roles.

All first nodes was created by my, with full html format, the rest was created with filtered html format, by affiliated users, for that reason, old nodes (my full html nodes) make the edit permission fail for others users roles, and new nodes (filtered htm format nodes) were possible edit for thoses affiliated users.

I just add, the affiliated roles to the "full html" format and they has edit permission for my old full html format nodes, again.

Thank again.
I'm going to close the issue

tomho’s picture

I had the same problem, this post really helped,

It was

The node uses an input filter not accessible by the user. (Security fail)

for me as well

freestylegary@yahoo.com’s picture

Life saver!!!

Thilan’s picture

Thanks for sharing this list. I was searching for the issue and finally found this. The problem is with the 1 (input format) you mentioned.

screenage’s picture

So, those permissions on input formats aren't really useful if this results in uneditable nodes, are they?
Though it seems logical that you can't make changes on the contents of a node if it has HTML you aren't supposed to use.

But a nice warning message / watchdog error should be useful