[Plone-UI] workflow issues

[Thijs Jonkman]

For our clients it is mostly the site administrator with manager rights
setting the sharing tabs, but only minimally, in which case I'd say use the
same terminology. I can also picture it being used in a more collaborative
intranet setting, where an editor would share, in which case I would not
lose the dumbed down version. I like Sean's solution for that.

It has not come up as an issue for our clients. I do not think that sharing
needs more prominence, it is useful, but it is not something everyone uses
every day. For users that do use sharing it is close enough in a tab.


On Tue, Aug 13, 2013 at 3: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 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?
>
> Sean
> _______________________________________________
> UI mailing list
> UI at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-ui
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20130813/b285c9bb/attachment.html>