[Plone-UI] workflow issues

Dylan Jay djay at pretaweb.com
Wed Aug 14 00:02:30 UTC 2013


On 13/08/2013, at 11:36 PM, Sean Upton <sdupton at gmail.com> wrote:

> On Mon, Aug 12, 2013 at 6:07 PM, Dylan Jay <djay at pretaweb.com> wrote:
> 
>> It's still confusing I think. It's not obvious that setting "Contributor" in site setup trumps "Can Add" in any sharing tab.
> 
> This lack of consistency in language should be repaired; I would like
> to see the role names stop being demoted there in place for
> pseudo-capabilities that sound like permissions and conflate things
> (the language on the inherit checkbox needs to go to, it is not
> "inherit permissions").

I agree consistency needs to be fixed.
However in my experience the use of the word "roles" has been very confusing for several of the teams I've trained and worked with. I think in the Plone UI we should call them something else (despite the confusion it might cause for those used to the zope definition of a role).

The reason is that most people use the word role in an organisation to denote a position with many different capabilities. e.g. newspaper editor. Zope uses the word role to mean the role taken in a workflow. For example a "newspaper editor" organisation role might be able to add articles, edit anyones and review them. So the first thing someone new to plone wants to do is add their organisation roles to plone. They then see "Roles" and start search goolge for "how to add roles in plone" and end up in the ZMI adding all sorts of roles. Instead they should be thinking of using groups and "capabilities". I believe if we take the word roles out of the UI, perhaps rename the current role names to make them all "pseudo-capabilities" then it would prevent the confusion. Contributor and Editor are also confusing. It's not clear that Editor allows you to edit other peoples work but doesn't let you add anything.
I also think integrating the sharing tab in with the workflow drop down might lead users to realise that the combination of state and sharing affect capabilities of a user in a context. For example we had one client that created 15 workflows which were all copies of the intranet workflow. Each change the staff-only state to newspaper-editors-only state etc. Then they used roles and placeful workflow to give those changed capabilities in the right folders. All that stemmed from a misunderstanding of roles and groups. 
Groups containing groups model organisation roles well, and local-roles model "capabilities" well. If the current state in Plone for instance said "private +2" and clicking on the drop down explained that in addition to whatever global capabilities are defined this context has 2 other groups who can view it. and perhaps move the sharing tab into the state drop down to show the relationship.
Another possibility is to support the organisation role in plone. Let users create groups of capabilities and given them custom names. or perhaps allow them to add groups in the sharing tab so it's easier to make a organisation role on the spot using a group. ie I'm in the news folder and I want to add in the news reviewers, I can click Sharing > Add group > select the names, title it "news reviewers" and select "Can Review" and "Can Edit" and "Can Add" then click save and that group only has that capability in the news folder.

I'm not sure how to test which of these will be the better UI however.

> 
> I think something like this in the sharing page column headings:
> 
> <th>
>  <h4 id="role-contributor">Contributor</h4>  <!-- localized role
> title as heading -->
>  <label for="role-contributor">Can add</label>  <!-- descriptive
> subheading text -->
> </th>
> 
> It also makes sense to me to avoid having a sharing tab visible on the
> site root?

As was pointed out share at the root and globals roles differ in that global roles can't be overridden. To remove the sharing tab on the root we'd need to provide "overridable" assignments in the control panel so as not to remove that functionality. Also it would be good to make that distinction explicit. 
To do that we'd need a assignment control panel for users and groups that let you choose between an "enforced" assignment and an "overridable" assignment. Makes that UI even more complex :(

> 
> Sean



More information about the UI mailing list