3

I am creating a publications database that is used by staff to input their publications. Some of these publications are available to the public, and some are not. Additionally, the publications have files associated with them, some being public and some not. I have a number of content types for different types of publications with a boolean public field, and two seperate file fields, one for public and one for internal files. I currently have one user role (Staff member) though the number of roles is likely to increase slightly to allow for administrators and a content approval workflow.

  • Content Type a
    • Public?
    • Public Files
    • Internal Files
  • Content Type b
    • Public?
    • Public Files
    • Internal Files

The idea is that all the publications lists should show a list of public documents to non-authenticated users, and a list of all documents to authenticated users of the right role.

My initial thought is to create two different views for each page with different access settings on each. The first being a page that doesn't check the public field and includes the non-public files field, and a second, available to anyone, that filters to publications where the public field is set to true, and does not include the internal files field, and a few other fields only of interest to staff.

  • node list view
    • view a
      • access: staff only
      • filter: Published nodes
  • node list view
    • view b
      • access: no restriction
      • filter: Published nodes AND public is true
  • node view
    • view a
      • access: staff only
      • filter: Published Nodes
      • fields: All Fields, including internal files
    • view b
      • access: no restriction
      • filter: Published Node AND marked public
      • fields: don't display internal files, some other fields

Is this the simplest, most drupalish approach? Would it make more sense to control the fields used through the view or via view mode (Full Content, Teaser, etc.) I'm still somewhat new to working with Drupal, and find that I'm fighting it at every turn, that makes me think, I must be thinking the wrong way for working with a drupal site.

Further Information: I'm actually reimplementing this from an existing system, and am using the Migrate module to bring in thousands of entries, so I have to be able to specify as part of the migration in some way, what the permissions should be.

2

Content Access

This module allows you to manage permissions for content types by role and author. It allows you to specifiy custom view, edit and delete permissions for each content type. Optionally you can enable per content access settings, so you can customize the access for each content node.

Video Tutorial

Field Permissions

The Field Permissions module allows site administrators to set field-level permissions to edit, view and create fields on any entity.

enter image description here


Your views approach is fine, assuming everything you need is in the view.

But if you want to restrict access to nodes, then you're better off using Content Access.

For example: If your view was listing links that you don't anonymous to access (eg: premium content) you would want to use the Content Access module because if anonymous users somehow get a hold of the direct link then they could see the premium nodes.

  • Before I dig into this further, would this also provide provisions for not showing specific fields of a content type to unauthenticated users? Not that that is a deal breaker, but it seems that I might still have the same amount of work to do in views whether the content access module is there or not? What is better about this approach than the one I proposed? Thanks! – UltraBob Feb 2 '16 at 5:36
  • @UltraBob updated my answer – No Sssweat Feb 2 '16 at 5:38
  • 1
    thanks! That is another piece of the puzzle I hadn't thought of. I already have field permissions installed to allow me to limit edit rights to some parts of the user profile. It seems that I can turn off view access for the internal only fields altogether for anonymous users, which if it works is great! – UltraBob Feb 2 '16 at 5:44
0

Apart from the previous (valid!) answer, I think there is another alternative to address at least this part of your question:

The idea is that all the publications lists should show a list of public documents to non-authenticated users, and a list of all documents to authenticated users of the right role.

The way I'd try to implement this, is to use the Group module for al documents targeted to authenticated users. For "public" documents you don't have to do anything I think. As per the "right role", that's a matter of creating the appropriate "groups" (like 1 for each role maybe?), and/or maybe even sub-groups that this module supports.

This module is like Organic groups "little brother", only started in D7 and with a D8 version at the horizon. Personally I'm more and more considering it as a potential alternative for the Content Access module also. And since it is all Entity based, there are lots of ways it can be used in combination with the Rules module also.

For way more details about this module, refer to my answer to "How to only allow a user to edit his/her own users?".

  • Thanks! It turned out field permissions was most of what I needed (hides internal files from non-staff), I layered on taxonomy access control on top of that and it seems to be working swimmingly. I'll add the group module to my reading list! – UltraBob Feb 12 '16 at 10:20
  • OK, thanks for the feedback. And enjoy digesting the Group module ... but guess what: there is not a lot of "documentation" about that module (yet ...), except from "reading the source" and "digesting the issue queue" (wait: I forgot to mention that "there" .... and I still need to digest the about 6 recent new comments ...). – Pierre.Vriens Feb 12 '16 at 10:25
  • 1
    Re: "there" Apparently questions about Drupal.org are verboten. – UltraBob Feb 13 '16 at 8:29
  • I prefer to not add any extra comments "there". Please use my contact info on my profile for more details ... – Pierre.Vriens Feb 13 '16 at 10:08

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.