Restrict node except for teaser/file/specific field/title...

The "list" checkbox doesn't work that way, unfortunately. It doesn't control whether the node is allowed to be listed; rather, it controls whether the term is listed on the node's page. This is something that confuses a lot of people, so it probably needs to be improved in the documentation at least.

The issue of how to allow nodes to be listed on the front page or in a view while protecting the content of the nodes is one I need to solve as well. One solution is to use CCK's field access control to hide everything but the node title from the roles who shouldn't see it, but that can't be controlled based on taxonomy (plus leaves a lot of empty node pages sitting around unless you do some extra work to hide them).

My plan for D6 is to create a module that allows TAC to interact with CCK's field access permissions:
http://groups.drupal.org/node/28700

Marked #645770: Teaser Access in Views as duplicate.

Marked #295811: Getting "private" documents to show up in Taxonomy queries as duplicate.

Situational alternative modules:
http://drupal.org/project/content_levels
http://drupal.org/project/premium

Attached module implements per-field access control using TAC's logic and UI. This can be used to restrict one or all of the fields of a node based on taxonomy without restricting the node itself entirely.

It works for the most part--controlled fields are displayed or hidden as appropriate from the settings--although it doesn't seem to properly deny access to private files in restricted filefields the way that content_permissions.module does. I haven't tested caching or indexing of nodes.

Re: the filefield issue, see #696906: filefield_edit_access() and filefield_view_access() should use content_access() instead of checking content_permissions specific.

The UI in #6 is a bit clunky and tedious if one is configuring multiple fields/roles. It would be helpful to have the option to clone from one role to another, from one field to another, and/or from TAC to TAC Fields, or perhaps to have "access profiles" that could then be assigned to field/role combos with a checkbox. See also #364060: Clone Taxonomy Role.

Also, this module currently allows restricting fields from user 1.

subscribing

@#10: If you are interested in this feature, any feedback you could provide on the module in #6 would be appreciated! (Just don't use it on a production site.)

thanks xjm, I downloaded #6 and am testing it today. So far it works as advertised.

FYI, I'm using a custom module which uses your tac_fields_field_access()

I've tested it with simple logic, which is to say a single node with one taxonomy term associated. I'll now test it against more complex situations. I'll let you know how I get on.

ok, so far so good. The existing TAC logic appears to be being followed for nodes with two taxonomy terms, with "Allow" taking precedence over "Deny". I'm not getting any error messages.

OK, sorry for silence, project had been on hold.

First bug, or at least behaviour I didn't expect is that, TAC appears to be set to "// Deny access by default for fields we do control." on line 215. That would be fine except it prevents new nodes from being created with that field being populated, since the new node form has no taxonomy terms attached to it.

As a followup to #14 it seems to me that, until another $op for "edit" is added to the permissions TAC fields controls, the quick fix is to add;

  if(!$nid){
  	return TRUE;
  }

somewhere around line 142 of tac_fields.module

subscribing

I'm going to go ahead and commit this to -dev (with massive caveats about it being experimental) so we can open specific issues for different things.

#14/15 is interesting; I need to think a little more about the implications there.

To -dev:
http://drupal.org/cvs?commit=403666

See #876254: Field may not be editable on node creation for #14/15, and #876248: Do not restrict access from user 1 for #9.