1

I'm looking for a reliable solution for the following situation:

  1. a membership site with multiple levels of access for users (based on roles, say anonymous, and levels 1 through level 4)
  2. need to restrict node view access by role on a per node basis, but allow anonymous access to the teaser (should be possible to show/restrict other fields as well)
  3. take performance and flexibility into account

There are several modules that solve most of the problem, but not entirely. I'm looking for recommendations on the combination of modules to use, and whether I'd need to extend any of these with custom code or if just combining contrib modules is feasible.

  • Premium content offers the basic functionality, but it seems to only work for the regular body field. Is it still a good option if you want to publically show or restrict other fields? (e.g. restrict the body as well as another text or file field).
  • Taxonomy Access Control: I like how you can easily change the access level per node by just changing the assigned taxonomy term. But how would I allow anonymous access to the teaser or other fields?
  • Field permissions offers all the granularity on the field level I would need, but I need the option to restrict one field (e.g. node body) to different roles on a per-node basis.
  • Or maybe do something with Panels (cf. this answer)?

A solution that plays nice with other modules (e.g. Views) is preferred (I think TAC would qualify here - e.g. filter by taxonomy, maybe use VBO for changing terms...).

How would you do this?

Update: I've looked into using Panels; whle I like the flexibility that a Panels-based approach offers, I doubt it's feasible for my use case.

Using Panels, the selection rule would have to be based on a combination of current user's role and node being viewed's term id, so for each selection rule you'd need 2 criteria and the 'All criteria must pass' setting. So each access level (except 'Anonymous') needs two variants: one for the combination of tid + roles that get to view the teaser, and one for tid + roles that get the full node.

Since there are 5 roles to take into account (anonymous + roles A, B, C, D) I'd need 9 page variants. This doesn't feel quite elegant, or would 9 variants be acceptable? (thinking about performance, maintainability etc.).

Another problem is that the Term ID criterium in the selection rule is per Content type, so if I wanted to use this for multiple content types I'd need even more variants. Since I need the 'All criteria must pass' setting for the combination of role and term id, I cannot add term id of two content types in one selection rule.

Another option would be to use PHP for evaluating the selection rule, but that feels like it may be defeating the purpose of using Panels. And code in DB is not a good idea, etc.

So unless I am overlooking a simpler way with Panels, it doesn't seem such a good idea (except maybe with custom PHP for selection rules...)?

6

I would use Panels.

Basically, for all of your Panel Pages, you would have two variants.

Each variant would have a Selection Rule based on the user role, one for the role and one for not the role.

Then on each, build up the content the way you need. Personally, I would make a custom node view for the restricted view, so you can use the Node Being Viewed content piece and just configure it to use the view mode you made.

The reason I recommend Panels is that it makes it easier to change things in the future without needing to get special-function modules to cooperate with each other.

  • How would you mark the access level each node requires - taxonomy? It's not just an anonymous vs registered distinction, but e.g. node 1 visible for level 1 role, node 2 for level 2, etc. There are at least 4 roles + anonymous, so that would be 5 selection rules. Is Panels still a good fit for this case? – arjan Jun 15 '12 at 14:10
  • OK, I think I better understand what you are trying to do. Yeah, I think I would make a Level taxonomy, assign these to the nodes, and still tackle the display with Panels. I think you would then need a variant for each term, and the selection rule would be a OR of the levels going up. – mpdonadio Jun 15 '12 at 14:17
  • I looked some further into how this coud work with Panels, but I have my doubts (see update above). Thoughts? – arjan Jul 26 '12 at 8:37
  • +1. Perhaps it would make sense to implement the access rule for yourself, allowing you PHP, without eval(). See (drupal.stackexchange.com/questions/33336/…) for some help getting started. – Letharion Jul 26 '12 at 9:21
  • 1
    Complicated problems need complex solutions. I don't think nine variants is a problem at all; we frequently have lots of variants for panel pages. Implementing as a PHP rule may make it easier to fine tune, though. – mpdonadio Jul 26 '12 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.