Permissions and Community Roles in *New* Staging

[Ray Augé，修改在16 年前。]

Hey All,

I'm just about done with phase 1 of the new staging enhancements, but I need some advice on permissions/role handling in the Staged Community.

Note:Terminology used here is still subject to change. Pipe in if you don't like it.

Phase 1 of "staging enhancements" was to create a workflow for page publication. Below are defined the terms and the actors participating in the workflow:

Terms:
- Proposal : This term applies to any content which enters the workflow.
- Review : A "Review" exists when a "Proposal" is assigned to a "Reviewer".

Actors:
- Staging Manager : This is either the Community owner or someone who has been granted MANAGE_STAGING permission. This actor has the power create or break a staging environment. (Any user who is owner of the community or has portal "Administrator" role has this ability. This actor is essentially outside the workflow as an omnipotent actor.)

Workflow actors:
- Editor : This actor participates in the final act of a Proposal. He can "publish-to-live" a Proposal. He can Reject a Proposal. He can edit the content of a Proposal. He can Comment on a proposal.
- Producer : This actor is the workflow manager in the sense that he directs traffic in the workflow. He can Reject a Proposal. He can Assign Reviewer(s) to the Proposal. He can Delete a Proposal outright. He can edit the content of a Proposal. He can Comment on a Proposal.
- Reviewer : This actor is a knowledge expert and represents the QA element in the workflow. Any number of different Reviewers can be Assigned to a given Proposal (e.g. representing different knowledge fields such as language, PR, legal, etc.). He can NOT edit the content of the Proposal. He can Reject a Proposal. He can Approve a Proposal. He can Comment on a Proposal.
- Creator : This actor represents anyone having MANAGE_LAYOUTS permission and does not fit into the roles above. They create content and edit pages which he can then "Propose" as a change into the workflow. He can edit the content of a Proposal. He can Comment on a Proposal.

With the roles defined above we have these five permissions which fulfill these roles:
- MANAGE_STAGING : Represents the "Staging Manager".
- PUBLISH_STAGING : Represents the "Editor".
- ASSIGN_REVIEWER : Represents the "Producer".
- APPROVE_PROPOSAL : Represents the "Reviewer".
- * MANAGE_LAYOUTS : (unchanged from current) Represents the "Creator".

Now, I have this one problem... when a Producer is in position to "Assign Reviewers". A list of users needs must be presented to choose from. The best way to do this is by having a Community Role because listing users by an associated permission is really not practical at all. This means having a default Community role called something like "Community Reviewer". This makes it rather simple to list all the users in the Community with that role.

So, should we create Community roles for all of these actors? or for those that are obviously not included.

We currently have:

Community Administrator :
Community Administrators are super users of their community but cannot make other users into Community Administrators. These are effectively"Creators" as defined above.
Community Owner :
Community Owners are super users of their community and can assign community roles to users. These are effectively "Staging Managers" as defined above.

So missing Community roles would be:

Community Editor :
Community Editors are users who have final approval over the content in the workflow of a Managed Staging environment.
Community Producer :
Community Producers are users who manage the workflow of a Managed Staging environment.
Community Reviewer :
Community Reviewers are users who who participate in the "Quality Assurance" of content in a Managed Staging environment.

Permissions required per these new Roles:

"Community Editor" requires MANAGE_LAYOUTS, and PUBLISH_STAGING.
"Community Producer" requires MANAGE_LAYOUTS, and ASSIGN_REVIEWER.
"Community Reviewer" requires MANAGE_LAYOUTS, and APPROVE_PROPOSAL.


Any thoughts on this?

[atul patel，修改在16 年前。]

Looks good.

Can any asset be tied to this workflow system or is it limited to
page changes?

--Atul

On Feb 19, 2008, at 3:02 PM, Ray Augé at Liferay's Community Forums
wrote:

> Hey All,
>
> I'm just about done with phase 1 of the new staging enhancements,
> but I
> need
> some advice on permissions/role handling in the Community.
>
> Note:Terminology used here is still subject to change.
> Pipe in
> if you
> don't like it.
>
> Phase 1 of "staging enhancements" was to create a workflow for page
> publication.
> Bello are defined the terms and the actors participating in the
> workflow:
>
> Terms:
> - Proposal : I'm uysing this term to apply to any
> content
> which
> enters the workflow. A "Proposal" exists when existing content enters
> the
> workflow.
> - Review : A "Review" exists when a "Proposal" is
> assigned
> to a
> "Reviewer".
>
> Actors:
> - Staging Manager : This is either the Community
> owner or
> someone
> who has been granted MANAGE_STAGING permission. This actor has
> the power
> create or break a staging environment. (Any user who is owner of the
> community
> or has portal "Administrator" role has this ability. This actor is
> essentially
> outside the workflow as an omnipotent actor.)
>
> Workflow actors:
> - Editor : This actor participates in the final act of a
> Proposal.
> He can "publish-to-live" a Proposal. He can Reject a Proposal. He can
> edit the content of a Proposal. He can Comment on a proposal.
> - Producer : This actor is the workflow manager in the
> sense that
> he directs traffic in the workflow. He can Reject a Proposal. He can
> Assign
> Reviewer(s) to the Proposal. He can Delete a Proposal outright. He can
> edit the
> content of a Proposal. He can Comment on a Proposal.
> - Reviewer : This actor is a knowledge expert and
> represents the
> QA element in the workflow. Any number of different Reviewers can be
> Assigned to
> a given Proposal (e.g. representing different knowledge fields such as
> language,
> PR, legal, etc.). He can NOT edit the content of the Proposal. He can
> Reject a
> Proposal. He can Approve a Proposal. He can Comment on a Proposal.
> - Creator : This actor represents anyone having
> MANAGE_LAYOUTS
> permission and does not fit into the roles above. They create content
> and edit
> pages which he can then "Propose" as a change into the workflow. He
> can
> edit the
> content of a Proposal. He can Comment on a Proposal.
>
> With the roles defined above we have these five permissions which
> fulfil
> these
> roles:
> - MANAGE_STAGING : Represents the "Staging Manager".
> - PUBLISH_STAGING : Represents the "Editor".
> - ASSIGN_REVIEWER : Represents the "Producer".
> - APPROVE_PROPOSAL : Represents the "Reviewer".
> - * MANAGE_LAYOUTS : (unchanged from current) Represents the
> "Creator".
>
> Now, I have this one problem... when a Producer is in position to
> "Assign
> Reviewers". A list of users needs must be presented to choose from.
> The
> best way
> to do this is by having a Community Role. This means having a default
> Community
> role called something like "Community Reviewer". This makes it rather
> simple to
> list all the users in the Community with that role.
>
> So, should we create Community roles for all of these actors? or for
> those that
> are obviously not included.
>
> We currently have:
>
> Community Administrator :
> Community Administrators are super users of their community but
> cannot
> make
> other users into Community Administrators. These are effectively
> "Creators"
> as defined above.
> Community Owner : Community Owners are super users of their
> community and
> can assign community roles to users. These are effectively "Staging
> Managers"
> as defined above.
>
> So missing Community roles would be:
>
> Community Editor :
> Community Editors are users who have final approval over the
> content in
> the
> workflow of a Managed Staging environment.
> Community Producer :
> Community Producers are users who manage the workflow of a Managed
> Staging
> environment.
> Community Reviewer :
> Community Reviewers are users who who participate in the "Quality
> Assurance"
> of content in a Managed Staging environment.
>
> I haven't ever done it... but is it possible to create roles which
> automatically
> are assigned certain permissions? For example:
>
> Community Editor requires MANAGE_LAYOUTS, and PUBLISH_STAGING.
> Community Producer requires MANAGE_LAYOUTS, and ASSIGN_REVIEWER.
> Community Reviewer requires MANAGE_LAYOUTS, and APPROVE_PROPOSAL.
>
>
> Any thoughts on this?
> --
> Liferay Community Forum
> [e-mail]
> http://www.liferay.com/web/guest/community/forums/message_boards/
> message/496901

[Ray Augé，修改在16 年前。]

> Can any asset be tied to this workflow system or is it limited to
> page changes?


Logically? Yes! because the model uses the classNameId/classPK paradigm.
But currently the requirement is to handle pages.

The difficulty of integrating this with all the individual assets will
of course be injecting the code which handles the Staging workflow into
every portlet which is subject to the workflow.

Right now (in my code) the issue of assets is addressed indirectly based
on Layouts... how? Because every portlet must exist on a Layout.
Therefore publishing changes to assets in a given portlet requires
publishing the Layout.

For example, under the "Managed Staging" scenario, when a "Creator"
creates/updates an Journal Article in the Staging environment,
publication control is controlled through the workflow only. This means
that in order to have the Journal Article published from Stage to Live,
the Layout containing the Journal portlet, which contains the Journal
Article, must be "Proposed" as a change (i.e. submitted into the
workflow).

Or alternatively, if the Journal Article is displayed in a Journal
Content portlet on a Layout withing Stage... this Layout could be
proposed as a change, allowing the workflow to handle it's approval and
publication... and when the Layout is Published, the Journal Content
portlet along with its Journal Article will be published as well.

Note for example that in most cases this works just fine... Consider for
example the Asset Publisher... where the configuration is simple a
collection of portlet preferences defining the tag logic used to return
results and the display settings... once defined the Layout containing
the Asset Publisher portlet is "proposed for Publication", and once
approved, the layout, portlet, and portlet preferences are pushed to
Live.

[Ray Augé，修改在16 年前。]

To clarify my question a little...

First, does anyone have a problem with me creating these system Community Roles (can't delete them) when they only apply in the Staging environment?

If so, how can we address the need for these roles when Staging is initialized?

Secondly, what is the most appropriate way to make it such that these Roles have pre-determined permissions... do I hard code them? Or does someone have a better suggestion... right now system Community roles pretty much have hard coded logic which defines them as special cases...

It would be nice if there was some way (other than hard coded) to specify the default permissions of system roles (Community or otherwise) so that they don't have to be hard coded in core logic.

Note that the staging permissions defined above all apply to the Group of the Staged Community.

[Jorge Ferrer，修改在16 年前。]

Hey Ray,

This looks very very good!

Regarding your questions, I pretty much agree with everything Ed said. In particular, I'd like to explore other alternatives rather than creating those roles. Be aware that we would have to create those roles not only for communities but also for organizations.

Also, I think we should try to avoid creating the list of available reviewers based on the roles they have. That would break user's expectations when creating custom roles that contain the appropriate permission. If we want to be consistent we should not check directly against roles and always do it against permissions. I understand that's quite hard and don't have a solution right now but we should try to find it since this need will come again and again.

[Ray Augé，修改在16 年前。]

> In particular, I'd like to explore other alternatives rather than
> creating those roles. Be aware that we would have to create those
> roles not only for communities but also for organizations.


K, noted.


> Also, I think we should try to avoid creating the list of available
> reviewers based on the roles they have. That would break user's
> expectations when creating custom roles that contain the appropriate
> permission. If we want to be consistent we should not check directly
> against roles and always do it against permissions.


Agreed, but the only other option available right now is iterating over
all the users in a group and checking if they have the given
permission... not very efficient.


> I understand that's quite hard and don't have a solution right now but
> we should try to find it since this need will come again and again.


So we need an optimized finder to list users based on some context and a
specified permission.. the context being either Organization, or
Community. For Orgs. do we cascade up into parent Orgs or not? As of
right now all I need is Community context so cascading is not an
issue... but it will be for the general solution...

PS: I need a solution imminently.

[Ray Augé，修改在16 年前。]

> Agreed, but the only other option available right now is iterating over
> all the users in a group and checking if they have the given
> permission... not very efficient.
>
>
> > I understand that's quite hard and don't have a solution right now but
> > we should try to find it since this need will come again and again.
>
>
> So we need an optimized finder to list users based on some context and a
> specified permission.. the context being either Organization, or
> Community. For Orgs. do we cascade up into parent Orgs or not? As of
> right now all I need is Community context so cascading is not an
> issue... but it will be for the general solution...
>
> PS: I need a solution imminently.


Thinking about this again... I'm not sure that there is any way we can
do this... for now I'm going to iterate over users and check
permissions... having a role to check would be so much easier... because
permission checks will inherit users you don't want in the list... you
only want to list users specifically assigned the task of "Reviewing"
content...

[Ton Hoang，修改在15 年前。]

verry nice, any update on it

thank

[Ed Shin，修改在16 年前。]

I don't really know what the requirements are, but looking at this from the perspective of teaching someone else how to use it I'd like to make the following suggestions:

If we're using MANAGE_LAYOUTS in core, then I think we should change it to MANAGE_PAGES. I think that makes more sense to most users.

I think both the "Community Owner" and "Community Administrator" roles should have permissions to do everything. To me, it makes sense that Community Administrators should be able to do anything except change the permissions of the Community Owner.

In terms of actors, what's the difference between Staging Managers and Editors?

I don't like the term "Producer" since it almost seems as if he should be producing content. Unfortunately, I don't have any alternative suggestions, so maybe we should just go with that term.

- MANAGE_STAGING : Represents the "Staging Manager".

I think this one is easy to understand

- PUBLISH_STAGING : Represents the "Editor".

As an end user, I'd have a hard time figuring out the difference between PUBLISH_STAGING and MANAGE_STAGING. Aren't they essentially the same, or does one have more rights than the other?

- ASSIGN_REVIEWER : Represents the "Producer".

I think this one is easy to understand too

- APPROVE_PROPOSAL : Represents the "Reviewer".

I'm not sure how intuitive proposal would be for an end user, but I think this one is good too.

- * MANAGE_LAYOUTS : (unchanged from current) Represents the "Creator".

I think this one is easy to understand too


From the end user perspective, I'd prefer not to add new roles. I think the less default roles that we have, the easier it is to understand. But if this means that the backend code will be complex, I'd rather go with clean code becauuse it will be easier to extend. Would it be possible to assign the permissions by User, Org, Loc, etc. instead of adding new community roles? If not, can we just add the Community Reviewer Role and not the other 2?

I hope these suggestions are helpful and not totally off the mark!

[Ray Augé，修改在16 年前。]

On Wed, 2008-02-20 at 07:30 +0000, Ed Shin at Liferay's Community Forums
wrote:

> I don't really know what the requirements are, but looking at this from the perspective of teaching someone else how to use it I'd like to make the following suggestions:
>
> If we're using MANAGE_LAYOUTS in core, then I think we should change it to MANAGE_PAGES. I think that makes more sense to most users.


I think the outputted term is actually "Manage Pages".


> I think both the "Community Owner" and "Community Administrator" roles should have permissions to do everything. To me, it makes sense that Community Administrators should be able to do anything except change the permissions of the Community Owner.


They do, and this is not changing!!!


> In terms of actors, what's the difference between Staging Managers and Editors?


The "Staging Manager" (a.k.a. most likely the Community Owner in 99% of
cases) has the ability to create/break the staging environment...

The reason for the distinction between "Staging Manager" and the
permission of MANAGE_LAYOUT, which is our "Community Administrator", is
due to the fact that, in order to allow some users to have the ability
to create pages, add portlets, etc.. you MUST grant them
MANAGE_LAYOUT... BUT we DEFINITELY don't want to allow those users to
BREAK the staging evironment... so we HAVE to make the specific
distinction...

Omni admins and Community Owners will always be able to create/break a
staging env... But some one who is just a content creator should NOT be
able to do this.




> I don't like the term "Producer" since it almost seems as if he should be producing content. Unfortunately, I don't have any alternative suggestions, so maybe we should just go with that term.


Yes, it's intention here was in the sense used in
"Publication/Print/Movie" production... the Producer essentially is the
broker in the workflow... he/she assigns tasks/is first line of
approval... but doesn't really have the last word... that's the
"Editor's" privilege.




>

- MANAGE_STAGING : Represents the "Staging Manager".

>
> I think this one is easy to understand


Good, note that this doesn't require a role per say... as "Community
Owner" will play this role OOTB (though the permission will exist to be
delegated to anyone).



>

- PUBLISH_STAGING : Represents the "Editor".

>
> As an end user, I'd have a hard time figuring out the difference between PUBLISH_STAGING and MANAGE_STAGING. Aren't they essentially the same, or does one have more rights than the other?


Keep in mind that many of these parts can be played by the same
person... for example, a "Community Owner" will, by default, play the
role of "Staging Manager" and "Editor". BUT, we need to address the role
separately in order that, when required, this role can be delegated
independently of Community ownership.



>

- ASSIGN_REVIEWER : Represents the "Producer".

>
> I think this one is easy to understand too


Good.



>

- APPROVE_PROPOSAL : Represents the "Reviewer".

>
> I'm not sure how intuitive proposal would be for an end user, but I think this one is good too.


I'm open to changing "Porposal". What would you suggest?


>
>

- * MANAGE_LAYOUTS : (unchanged from current) Represents the "Creator".

>
> I think this one is easy to understand too
>
>
> From the end user perspective, I'd prefer not to add new roles. I think the less default roles that we have, the easier it is to understand. But if this means that the backend code will be complex, I'd rather go with clean code becauuse it will be easier to extend. Would it be possible to assign the permissions by User, Org, Loc, etc. instead of adding new community roles? If not, can we just add the Community Reviewer Role and not the other 2?



We will be able to grant these permissions to User, Role, Org. The
problem is finding users within context (in this case the Community) who
have a given permission... this is currently best handled by using
roles..



Use case for the workflow:

A "creator" has just created a new page. He decides that it is ready for
publications. He then makes a "proposal" to the "producer" to have this
new page published. The "producer" makes an initial review. The
"producer" has two options: reject, or grant that the proposal has
sufficient merit to be published. The "producer" may "comment" on the
"proposal" suggesting some initial change, after which they would deem
the proposal worthy of "official review". The "creator" reads the
comments, and makes the change. The "creator" comments that the change
was made. The "producer" sees the change, and assigns "reviewers" to
look at the proposal to ensure quality. Once every "reviewer" has
granted their approval of the proposal (after some back and forth
changes & discussion with the producer and creator), the "proposal" is
made available to the "editor". The "editor" now has the final word as
to whether to grant the "proposal" and ultimately to publish it.

[Michael Wu，修改在15 年前。]

I was wondering if these roles are implemented in the current binaries? or where can i find them?


On the current binary, community only has Community Administrator, Community Member, and Community Owner.

Is it possible to create the roles you mentioned above ourselves and add it to Community.

Thanks.