It might be a novice question, but up until now we had a centralised publishing system, and we are moving to partly decentralise it.
So if anybody have an advise / best practise or problems they had to deal with it will be much appreciated if you share your experience.
I am not even sure I understand difference between user group and user roles
We want our publishers to use simple edit interface / asset builders as they will not be creating complicated structures.
Thanks for your help
Roles are generally not used/recommended for a single-site system (i.e. where there is only one Site contained in the MySource Matrix system). Roles are used to abstract permissions and workflow from specific user groups so that you can use a single workflow schema or permissions configuration across multiple sites and assign different user groups to each site.
For your main question though, its a bit vague to give very specific answers. 
Its really about determining what exactly you want your distributed authors to be able to do. For example, you may want them to be able to upload images or documents to specific locations, but not actually create new pages within the site. This is quite a common configuration. Also, make sure you have workflow applied so that distributed authors are not able to change live content.
From an implementation perspective, its good to select a trial group that are willing to be testers and give them access first. Then you can work through any issues/problems they encounter before making it available to a larger group.
We are currently looking at clients that are using groups in their production systems. If there are Squiz clients using groups, please let us know
Thanks.
We use roles with groups and LDAP users to deal with workflow with some 200 or so (so far!) editors.
We have three roles - contributor, gatekeeper and basic admin. We also have three workflow "levels" - no approval, web style approval, and gatekeeper then web style approval.
By using roles, we only need these three workflows, rather than one for each area of the site. Having the contributor role at the start of the workflow also means that "up for review" emails go to the right place - again, without roles, we'd need a separate workflow for each of these. We also don't have as many problems with inheriting permissions to the wrong places since we've been using roles.
Roles really does eat database power though. The more records in the roles table, the worse it gets, even if you're not a user who's permissions are applied by roles (i.e. the public user) it gets slow. We had to make some SQL changes to the core to get any level of acceptable performance; I think those changes have been back ported into 3.16.1 now though.
See this thread for details: http://forums.matrix.squiz.net/index.php?showtopic=3881
...with a caveat that said thread is quite technical :rolleyes:
The change has been committed to the development version, and will be in 3.18 apparantly. Looks like I'll still need to be running patch files for a few more months then :ph34r: