views:

56

answers:

2

I'm trying to find a simple solution to a specific problem, which is a way to allow bloggers on my site to be able to control permissions on individual posts. So they could decide whether to have their post show up for all visitors, or for authenticated users only.

The closest module solution I've found so far is the Node Access module. It comes very close, but it doesn't quite do it for me, in the sense that it creates a new "grant" tab to the content type, then displays checkboxes with too many permissions options (allow a role to view, edit and delete), where I only want to display the view option, and I need it to be located right on the content edit/create page, not in a separate tab.

Unless I can find an alternative simple solution, I'll have to add a hack to the blog module or something. I can't think of any other way to do it.

Any ideas?

+4  A: 

If you want to avoid coding and keep things simple, there are a couple solutions that come to mind.

  • TAC Lite allows you to associate a vocabulary with an access control schema. Each term can be associated with different view/edit access permissions for specific users or roles of users.

    In this case, you would want a single term in the configured vocabulary. Set it up so that this term ("Restricted Access") when set, limits access to authenticated users only.

    The advantage of TAC_lite is the flexibility of building out your access model as new requirements show up- such as having "premium subscribers" gaining access to even more restricted content.

  • Content Access allows you to set access control rules by content type, and override by node. I can't speak to the UI, as I've not used this mode.

Grayside
+1 - We used TAC Lite in the past for something similar. A straight solution, as long as there are no other node access modules in use. See http://drupal.org/node/270000 for details on that.
Henrik Opel
Thanks for the suggestion Grayside. A very useful find for other parts of the multi-level roles site I'm building. I don't see yet how to make it work for this particular problem, but will continue to experiment.
Michael D
I am proposing to use a single-term vocabulary with tac_lite to toggle denial of access to anonymous users when that term is attached to any given node. It is heavyweight for this purpose but faster than coding.
Grayside
Oh! Of course! Now I see. This looks like the solution I was looking for, thanks!!
Michael D
maybe this one too: http://drupal.org/project/node_privacy_byrole ?
gpilotino
The maintainer of Node Privacy by Role wants to deprecate that module and migrate users to Content Access.
Grayside
A: 

In case Graysides (good) suggestion does not fit, you could do it yourself without 'hacking' the blog module by implementing hook_nodeapi() and hook_form_alter() in a custom module:

  • On the hooks 'load' operation, you could add a check for the nodes current access settings concerning anonymous vs. authenticated users. You'd add a property for that to the node object (be aware of potential naming clashes - you should prefix the names of custom properties in the node object with your modules name).
  • Via hook_form_alter(), you'd add a form element (e.g. radio buttons) to the node edit forms for your blog nodes that allows users to select the visibility, defaulting them to the new node property from above.
  • On insert and update operations of hook_nodeapi(), you'd then check the new property again and adjust the nodes access settings accordingly.

Note that this approach would possibly interfere with other node access module actions, so it might need some refinement. I do not recommend it - I just wanted to suggest an alternative to 'hacking core'.

Henrik Opel
Yes, thanks Henrik. I do see that it's unnecessary to change core code. A custom module looks to be in order. I'm just not quite up to figuring it out right now. It would help a lot if there were example snippets in the Drupal API pages, like there are on the PHP manual site. Another possibility that might be more my speed is to pull relevant code from other simple access modules to create the functions that I need.
Michael D
Yes, this is the code-based approach to take if an existing access module does not suit. I might use Flag or CCK as the form widget to take advantage of all the module integrations they provide (Views, Rules, etc).
Grayside

related questions