This is a general discussion page about permissions profiles in Tiki

Tiki 2.0 offers 221 different permissions that can be assigned to any group. Tiki offers a very fine-grained permission system but it's overwhelming for a new admin. One of the goals is to have sensible defaults. But with such a versatile tool, sensible default are quite different per use case. So, the following permission profiles are meant to help accelerate the configuration.

As always:
  • All permissions can be modified
  • You can create any number of groups and include groups in groups, to inherit permissions.
  • Users can part of as many groups as you want

Permission profiles

The following use cases have been identified for which we'll set standard permissions. Then, as admins activate features, the permissions will already be set.


Classic one-to-many model, feedback is not made public

Publishing with UGC

Possible to register for trivial things but it's clear that it's not official content
Publishing With UGC Permissions

Open community

Very open but more cautious than Intranet-Collaboration because anyone can register. P2P

Open Collaboration - Full Profile

This is a fairly wide open permission regime. It does not allow anonymous wiki edits but anonymous users can participate in forums, post comments, upload attachments and view pretty much everything that had not been categorized (made private).


Efficient collaboration between company and its customers/partners, limited interaction between customers. See Help desk vs Bug_Tracker. More of a customer service approach. Interaction between customers is monitored (ex.: forums)


A company or team in collaboration (can trust users)

TikiPress MU

TikiPress_MU will allow you to sign up power users (editor group) that can do a whole lot, but are managed by senior editors, and regular participants have basic perms.