ReviewRevamp

I recently built my own PTK site, and it was quite an educational experience. I ran into a number of roadblocks which no one has yet complained of. For shame! (And shame on me for putting up roadblocks in the first place.)

The most accute problem I ran into was that the reviewing system was FAR too simplistic for my needs. I want to be able to make content available to classes of users, rather than to just everybody. For instance, I may want members who are marked as employees to be able to see content that I don't want clients to see.

The good news is, the underlying machinery supports this. Reviewing works by simply twiddling the View permission on individual objects. There is no reason it couldn't give the View permission to the Employee role rather than to Member. No reason, except that you can't tell it to.

I propose to add an additional input to the Set status interface. This widget would list all the relevant Roles the user has, and allow the user to toggle them on and off. When the reviewing machinery updates the View permission, it gives it to any Roles selected in the box, rather than blindly using Member. If none selected, assume a reasonable default.

New

The actions that a Member who is not also a Reviewer can perform on an object's RoleMask are determined by the object's review_state. While an object is private or pending, the Member may modify the mask without restriction. While an object is published, roles can only be removed from the RoleMask. If roles are added (and some option is selected?), the object reverts to pending, and must be approved by a Reviewer.

Possible values for RoleMask will come from a policy hook on the Portal object (?) which is passed the AUTHENTICATED_USER and the object and returns a list of strings. (Okay?)

Question: can a Reviewer approve content destined to be shared with a Role that THEY do not possess?

[TWilson]: I think that the reviewers would have to have that power or things could get unduly complicated. (I'm not sure how, mind you. It just seems like that's more complicated that it needs to be. How could this be abused?

Assumptions:

Please take a moment to sanity-check these assumptions. I'll be using them to make some design decisions.

• A user shouldn't be able to share content with Roles that they do not themselves possess.

  ChrisW?

  Would this prevent a member sharing content with a manager? (Kindof related: is there a security Wiki anywhere?)

  joker: Why not? The content still goes through the review process... so we could think of it like someone is making sort of a recommendation or a proposal. On the other hand this could still be reached by entering a comment when requesting review that the content is directed for another group. So if this speeds up things at the moment...

  TWilson?: I wouldn't want to make those changes by hand very many times. MikeP?'s solution would be great.

  MikeP?

  "Sharing with a manager" doesn't actually make sense. All content is available to anyone with the Manager role (in it's context). I couldn't prevent that if I wanted to.

  My reason for wondering was that you may not wish to reveal the existance of a class of users. Is this not a common concern?

• When a user has only one relevant role (ie, Member in most cases) the option should be collapsed and the interface would appear the same as it does now.

  Can anyone think of any reason they might want to allow sharing with Roles not possessed by the user, or why they may want to hide Roles the users does have from this interface?

  [webmaven]: If you are using the PTK to build an Intranet/Public website, for example, you may want your internal authors to make certain content visible to various classes of external users. It would generaly not make sense for your internal users to actually have these roles themselves.

  [TWilson]: Example: Let's say I have a class of students who will be contributing content to my course's Web site. I, as the teacher (presumably using the role of Teacher), would probably want to review their contributions and make them available to other users with the role Student. But I probably wouldn't have the Student role myself.

• A user should be able to change the roles content is shared with without having to have the change reviewed. That is, selecting new roles in the selectbox does not affect the review_state of an object.

  [webmaven]: This would have to be configurable. I can see a situation where confidential internal information could be deliberately leaked in this way.

  ChrisW?

  gotta agree with webmaven. I think it's critical that if the roles the content is visible to are changed, then it needs to be re-reviewed. Otherwise, you could write an internal document, get it reviewed and then maliciously give the public roles access to it...

  [webmaven]: The question is, does the content go back to a pending status (hence invisible) or are somehow only the changes pending review (content changes as well as visibility changes)?

  [dlpierson]: If nothing else, this is a hole to avoid the reviewing process for site wide visibility. Just get reviewed for a small group then change the roles content to site wide. Not good...

  [pedxing]: If you want to model a review process with this, I think you are wrong to rely completely on the reviewers for it. It makes more sense for each role to have a RoleMask property itself, which lists the roles they are able to promote a document to. This way, a member with an "Author" role could only send a document on to those with a "ProofReader?" role, who could send it on to those with a "PolicyApproval?" role (or back to the "Author"), who could make it available to the public (or send it back to the "Author"). Of course, an Author/ProofReader?/PolicyApproval? member could release a document to any of these groups, since the approval list for a Member would be the union of each RoleMask for each of their roles.

  MikeP?

  Is it safe to allow a Member to remove a role from the RoleMask without reverting to pending status?

  [sburch]: "safe" but undesirable. Maybe it could be a switch that can be thrown on an object during the review process. If one role group can see it then another has to be able to see it (I'm thinking Company/Union relationships here).

  [TWilson]: That's good thinking. There are all kinds of nasty political things that could happen when people starting messing with viewing permissions without further review. Paranoid? Yes. Necessary? Probably.

• "share" is a useful and appropriate word for this action.

  Yup, right word, which is why it needs to be controlled. Information sharing, particularly in the intranet/extranet example, needs to be securely controlled. (Please "sign" comments)

• Zope Roles should be used to model classes of users. Members do not need to be able to create and manage new classes of users.

  What if members could define their own classes of users? Is this desireable? Could roles still work? (This seems like a hard thing to do to me.)

  [webmaven]: I don't see why not. This would seem to fit within the general "customers who have customers" approach that Zope is built on.

  [dlpierson]: While webmaven is right on principal I think that allowing this could lead to all sorts of breakage because the new roles might not get the correct permissions. At the least this would lead to members having to understand and have access to security settings.

  [TWilson]: The overwhelming majority of my portal's members will not have any reason or desire to establish their own user classes. Things must be simple by default for the "ordinary" portal user. There could always be an additional role (Member+ :-) that would have these extra capabilities.

  [k_vertigo]: Wouldn't most of these problems go away if somehow roles could be viewed as heirarchial.