Permissions Best Practices

Permissions are controlled in eCrowds by Roles and Security Policies. Roles determine blanket module abilities, like creating a page, and Security Policies determine permissions to specific objects. There's a four layer inheritance for Security Policies:

• Global full access
• Site-wide default Security Policy
• Module-specific Security Policy
• Object-specific Security Policy

That is, the system first checks the object (e.g. the page or idea) for a Security Policy, then, if not found, checks the module's Security Policy, then, if not found, checks the Site's Security Policy, and, finally, grants full access if no Security Policy is present.

Community Wiki Example

How would the permissions work if you wanted to set up a wiki for your community? The best way to do it would be to set up a Security Policy at the Page module level that allowed community users to manage in addition to setting up the Site's default role to allow create and edit of pages. Then, for your non wiki pages (e.g. marketing content), you'd apply a specific Security Policy that only allows certains users and groups to manage them. You'd also apply that same, more restrictive Security Policy to your Content Types to lock down which Content Types Community Users are allowed to use (e.g. only allow them to create wiki pages and use the wiki taxonomy).

Sign in | Free trial sign up | Follow eCrowds on Twitter