Content Access should respect ACL created without CA

I've also ran into this same problem... found that the taxonomy_access_control module was causing the conflict (see known & allegedly closed issue = http://drupal.org/node/145329)

Although the issue above has been closed, it doens't tell you the solution other than disabling TAC which does work... but i need them both and i've tried setting various priority flags on CA but nothing is working

Try changing the "Give node grants priority" under the advanced collapsible.

I have tried this option "Give node grants priority" but have the same problem.
Any Ideas?

I have the problem, too: content_access indeed does nothing: Installed with and without acl module, granted and revoked rights on admin/user/access and then on admin/content/types/story/access in various combinations: always the grants on admin/user/access are taken and the other are ignored (weight set to -10, 0 or +10).

Now happy without content_access / acl (it works) but not happy with the form admin/user/access (much too unclear design when grants are ordered by english alphabetical description and not by node type/grant type). The design in admin/content/types/story/access provided by the content access module on the other hand is very clear!

But I have to say: on some days it worked well, but some maintenance lead to no longer working content_access and thus I decided to uninstall as there is much more important to do than finding and isolating errors.

btw: I decided to say good bye to Joomla and to go to Drupal for the granting system in Drupal and the content_access module. Now I do not know if this decision has been the right one.

Edit
Now it gets weird! Moved the site from subdomain.domain.de to domain.de and: admissions did not work correctly. I thought, remainders of the admission records still exist in the system and are used. So I reinstalled acl and content_access with the idea to delete all remaining permissions. But then: (without doing anything else but reinstalling!) everything seems to work perfectly! I also could delete all edit permissions from admin/user/access and the content type permissions worked for me.
So this seems to be not only a problem of acl and content_access but also of the drupal built-in admissions system.

You should uncheck all permissions (except create permission) for all node types you want to use content_access for. Thus you won't run into troubles with permissions you do not expect for some users.
Some of the built-in node permissions have side effects:

• admin content permission: implies full access to all nodes and node types: create, edit, edit unpublished, view, delete.
• edit own content permission: implies full access to the author's nodes: edit, edit unpublished, view, delete
• edit content permission: implies access to nodes of this node type: edit, view, delete, but not edit unpublished!
• create content permission: allows to create content of this node type. If the node is unpublished by default, the author can not edit a newly created node again (unless he/she has edit own content permission)

With content_access you can distinguish between delete and edit permission. Edit permission does not imply delete permission, but delete permission requires edit permission!

Also with content_access and acl you can create permissions on user/node level instead of role/node level. An then the role level permissions (of content_acces only) are overwritten by the user level permissions (of content_access only) and ORed with the role based permissions of the Drupal built in node access (but if you have switched this off, it does not influence the result!)

Subscribed. A also have a problem with "the author can not edit a newly created node again" if a node is unpublished by default.

@Druppi:
Nice explanation, however:

but delete permission requires edit permission!

This isn't correct, you can have only Delete permission - try to navigaie to node/XXX/delete

Some add-on info about "the author can not edit a newly created node again" - this true, if unpublished content type is a page, but if unpublished content type is a book, that author can edit them

Also my experience, unfortunately - installed content access and acl modules, set 'Enable per node access control settings' for the content type at issue, but it does nothing at all, so far as I can tell.

Fago,
I think I understand the issue and it is a bug. Currently Content access implements only the ACL it creates through the form. As far as I understand node_access_records doesn't check if node is assigned to an ACL.

In order to test:
1. Disable content access
2. Use this test and patch to enter a node to an ACL using workflow_ng
3. Enable content access - it is now expected that the module will write the records to {node_access}, no?

Ok, here is a patch that should fix it. There is a patch also for ACL, as it needs to provide the ACL(s) of a certain node.
Test it according to #13 comment (i.e. don't add the ACL through the content access form)

Some code changes, so it will look nicer. There is a bug though, but I'd require some help on it.

Scenario:
1. Add user to ACL using content access form.
2. Add node to ACL using wf_ng - There is a key duplication in the INSERT to {access_node}.

amitaibu, thanks for your effort, but I think you got on the wrong road. There is no need to directly call the acl module, the drupal node access system is designed to handle multiple node access modules at the same time. So content access and acl work to gether on top of that API, such as content access works together with every other node access module.

So the way this works is:
* modules may only insert grants. When at least one module grants access, access will be granted.
* if a module has higher prioritised grants, only this grants will be applied. Lower priority grants are ignored.

for other bugs, please open new issues so we keep the discussion clear.