'access unpublished page/story/blog content' set of permissions

Hi Rik and John, thanks for trying to make sense of my prior long-windedness.

I feel guilty putting in feature requests when Rik has worked so tirelessly to give us what is already fantastic stuff. I am wary of activating other modules. I tried out nodeaccess, and it required permissions to be rebuilt; but it seems that on huge sites this operation uses ever-increasing memory and therefore fails, so I took that module out before I got bitten! I don't know if this (rather serious!) problem also exists for TAC-lite. If we can make Rik's hot stuff do the job, I would be more than happy.

Standard drupal has a curious hole in the permission system. All manner of edit, delete, create, permissions exist per content type, but not 'view'! View comes either by being an excessively powerful user, being the creator, or the work's being published. So very coarse-toothed a comb I almost cannot believe it. It seems the basic drupal view permission is: anything, unless unpublished. So when module_grants opens up unpublished works, view anything comes along automatically. I think that is the central problem.

I am not sure whether John's request will solve the problem. Basically, a site I am developing for a nonprofit society has some other societies supporting it, and the others are to be given their own group of pages on the site. Since there are two, and maybe more, and these are independent, I will need to set up two node types and I can set create own, edit own, etc permissions so that each of the two supporters can develop their own pages. At least one page, the 'home' page for each supporter, will be created by me and owned by me for them to edit and insert their links into directing to their own new pages. But if I am following you, if I set "New revisions in draft, pending moderation" for the two content types, both supporters will be able to see all pages of both, rather than just their own. The reason it is limiting is, I suspect, that it attacks the problem from the point of view of the target node type, but the solution needed is from the point of view of the specific author's permissions. Rather than say "This node type can only be seen if..." I think it needs "This role can only see these node types." That would allow some other role to be given greater rights. Since only one small thing (specifying rights for viewing when unpublished) is missing from drupal in order to make it all work properly, I wondered if this kind of thing is hard or easy to get in there? Manipulating the node_access table is obviously a very dangerous thing to have a site rely on.

As I write this now, it occurs to me that another (perhaps simpler) way to get the required effect would be a "Can only view unpublished if can edit" anti-permission, since edit permissions can be allocated acceptably with standard permissions, and the need to see unpublished might be expected to go with edit rights, if they are restricted at all. Expressed in positive language, that would be "Can view unpublished even if cannot edit" - which is the way I understand permissions to work. Users without that would only see what they can edit; the site owner would have it and therefore be able to see all unpublished content.

Apologies for finding this hard to explain!

Thanks again Rik, cheers!
Ron.

Thanks Rik,

I have had a go at implementing the suggestion of this feature request, by introducing a per-nodetype permission for accessing unpublished content. (I just noticed you checked in some more changes since I collected the HEAD and started hacking, so I hope I am not at too many cross purposes.)

My changes add these permissions:

Under module_grants module:

access content summary	 	 	 	 	 	 
unpublished book access	 	 	 	 	 	 
unpublished page access
...etc.

Then it changes the rule for granting access as follows. Change:

  if (!$node->status && !user_access('view revisions', $account)
     && !($op == 'view' && $account->uid == $node->uid && $account->uid > 0 && get_number_of_revisions($node->nid) == 1)) {

To:

  $which_perm = 'unpublished ' . $node->type . ' access';
  if (!$node->status && !user_access($which_perm, $account)
     && !($op == 'view' && $account->uid == $node->uid && $account->uid > 0 &&
         (user_access('view revisions', $account) ||
          get_number_of_revisions($node->nid) == 1))) {

Rationale: The new rule is saying: "If the node is NOT published and user does not have the "unpublished xxx access" permission, deny access, UNLESS it's the author (viewing their only revision OR possessing "view revisions" permission)"

So a user withOUT "unpublished xxx access" cannot see any but their own work, in which case "view revisions" is used to test whether they can see multiple revisions; but a user WITH "unpublished xxx access" can see all unpublished for which they pass other tests. This effectively grants a "view revisions"-style permission in that restricted set. One might consider whether "view revisions" should be required anyway in that case if more than one revision exists.

I am still working on this, and I'll post again, but I wanted to give you a progress report.

Ron.

Hi again Rik,

I have checked out my changes above, and AFAICT, they are doing what they are designed to do. There is only one missing distinction: In my scenario, I can get the special user to be able to publish and unpublish their own type of page, but that also includes the special page which the site owner sets up for them to edit, which is a problem. With a bit more struggling, I think I could get that to work too, but I wonder if there comes a point when the benefit isn't worth the complexity. For now I'll leave it as-is and test it out a bit more.

Ron.

Thanks Rik,

I think it demonstrates what a well-designed and conceived module it is, that such a change and extra function can be made with relatively little pain.

Cheers,
Ron.

Hi Steve,

Thanks for giving the patch a run-over. Yes, the reason I put in that if statement was that I copied the code from node.module that produces the list of permissions like "delete own xxx content" etc. I'm flying by the seat of my pants here, having fun but basically being clueless. Now if we take out that if statement, the next question is: why does node.module have it? Why aren't there permissions available in the core for doing stuff to blog, forum, etc? How does the system know who is entitled to do stuff to that stuff? I have this awful feeling that I don't understand something very important - unless I copied the wrong loop by mistake!

Looking forward to your insights!

Ron.

Hi Steve,

Yes, that sounds right... Checking another website of mine, I see that you are correct - blog has a separate section, and if its permissions had also appeared under node, they would have been duplicated. So the if statement is superfluous. Here is a modified patch.

Ron.

Hi Rik,

Thanks for all your hard work lately! I haven't actually downloaded the latest version because what I now have is doing fine - and you know what they say about sleeping dogs... So I haven't tried this new feature, but from what I read, it sounds as if the two are slicing things in perpendicular directions. The new feature is implementing a distinction between own and any, but my patch implements a distinction between node types. If I understand it properly, they should not interfere and they both serve someone's purposes. If I get some free time I'll put the latest version on my local test site and see what I can see.

Cheers,
Ron.

Hi Rik,

I have finally tested your 2.7 (looks really nice, thank you!). I have added my unpublished access patch, and it does indeed operate orthogonally to the other features you have added to 2.7. Although my site is reasonably simple, I get all the expected behaviour. The patch in the earlier comment #14 won't work, though, because you have made so many under-the-hood changes. Here is the same patch made against version 2.7. I believe Steve is using this patch too - I hope it is working out okay.

Cheers,
Ron.

Oops, In the previous comment I actually mean version 2.6. Don't know why 2.7 is floating around in my head. Sorry!

Sorry I've been sidetracked for a while, and didn't see your reply.

I don't know what to say in reply to your comment about complexity and confusion. It doesn't confuse me: Drupal supplies options for everything except view unpublished, so this supplies it. The wording of what it does is self-explanatory and it completes the so-far inconsistently unfinished set of possibilities. I don't know how that is confusing. Steve said above he is using it too. Since there are only a handful of people actively contributing here, if two of them find something to be just what they want, presumably it is of more than marginal use?

And no, view revisions of own... doesn't cut the mustard. My case is that I want certain trusted users to see all unpublished stories so they can plan their own work to fit in. View own is simply wrong for the purpose. Or if it can be used, please tell me how to do it, because it certainly baffles me.

The basic motivation behind my wanting to make this module complete even if it means not quite so simple is that I don't want to implement any of those modules that change node permissions. I have read of many horror stories of the permission recalculator failing to complete and leaving sites broken. If we can do this with conditional logic that is simply tested per access, it avoids a huge danger to robustness.

I looked at View Unpublished and it confused me. The instructions say to install Override Node Options as well, which allows selected roles to publish or unpublish. While that might be nice, I don't need it and I don't see why a view module should require it. But when I go through the View... code, I cannot see anywhere how it actually makes nodes viewable. (Your code Rik, despite being so much bigger, makes sense to me.) So maybe it is relying on something in Override... after all? It feels very disquieting, as well as making me wonder how these modules will interact. I have tried to stick with just your modules for that reason - no unforeseen interaction troubles.

Thanks Rik, that looks interesting. I'll give it a go on my local copy. I'll let you know how it goes.