History for ReviewRevamp

??changed:
-
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.