How to allow users to add content

From Sense/Net Wiki
Jump to: navigation, search
  • 100%
  • 6.3
  • Enterprise
  • Community
  • Planned


Create content

Sense/Net ECMS has a flexible Permission System that allows you to control who can do what in your system. There is a special case though: when users, even anonymous users (visitors, as they called in Sense/Net) need to create content. In this article you can learn about the best practices and necessary steps you need to make when allowing this scenario.

Decide what content types to allow

This article is about permissions, but before you grant permissions, you need to make sure that the Allowed Child Types setting is correct on the container where you want to allow content creation. This is necessary to keep the content repository organized a manageable.

If you do not set Allowed Child Types on a container, users - even administrators - will not be able to add content there.

Setting allowed child types

Permissions on the content type

Users will only be able to add content of the types you provided above if they have See permission on the Content Type itself. For example:

  • /Root/System/Schema/ContentTypes/GenericContent/Folder

Permissions on the application

In Sense/Net ECMS content operations are handled by applications. In this case you need to grant RunApplication permission for the Add application of the container (e.g. a folder, a workspace or a content list). For setting the necessary permissions on the application, visit the following article.

Permissions on the container

When you want to allow someone to add content somewhere in the Content Repository, you need to grant at least Open and Add permissions on the container (e.g. a folder, a workspace or a content list) for the group she belongs to.

It is recommended to grant permissions for groups instead of individual users to make permission management easier.

Before version 6.3, Run application permission is also mandatory on the container.

Accessing content created by others

It is an essential role of the permission system to control what content are accessible for the users. If it is OK for users to see content created by others, than you can simply grant the permissions on the container mentioned above.

But in some cases a more secure approach is required: for example when you want to allow visitors to add content (e.g. fill a form) but you do not want them to see content created by others. Or there is a survey for internal users where you do not want to let users to see others' survey items. In this case you may need to break permission inheritance and add local only permissions instead of inherited ones.

Break inheritance

If the container where you want to allow adding new content resides in a subtree where users already have Open permission, you need to break permission inheritance, remove the inheritable Open permission and grant a local only permission. You may choose however the place where you want to perform this inheritance break as you'll see in the section below.

Break on the container

The easiest way is to break inheritance on the container (e.g. a Form) manually and set local permissions there. This does not involve any additional coding. The disadvantage of this solution is that if you change permissions above (e.g. add additional permissions for a new editor group on the site or workspace level), you will have to add that to the container in question (the Form or Document library) too.

Break on the created content

If you are willing to do some coding, than you may keep the permissions unbroken on the container and modify the permission settings on the newly created items programmatically at the end of the creation process. For example break inheritance and remove all permissions except the ones related to the Administrators group. This way the container will still inherit permissions from above, but you'll have to write the code manually (e.g. in a Content Handler or NodeObserver) and the system will have to store a lot more permission entries.

Permissions for Creators

In Sense/Net there are a couple of Special groups that let you fine-tune your security settings. In our case you may want to allow creators of new content to access the content they created - but do not allow accessing content created by others. This is what the Creators group can be used for: the permissions set for this group applies only for that particular user who created the content. This allows you to set general permissions for one group (the Creators group) only once on the container - for example grant Save permissions for creators. In that case everybody will be able to modify their own content but not others' . This is useful in case of logged in users. In case of visitors, we have a separate logic as you can see in the next section.

Local-only permissions

For details about local-only permissions, please visit the Permission system details article. In our case you will likely add a local only Open and Add permissions on the container for the users you want to allow content creation - e.g. Visitor user or IdentifiedUsers group. The point is: these permissions will only be related to the container and newly created items will not inherit them. This prevents users from seeing each others' content.

Local only permissions

Owner of items created by visitors

Because in Sense/Net ECMS anonymous users are represented with one special user called Visitor, we need to change the creator user of newly created items. If we did not do this, the 'creator' (owner) would be Visitor and everybody would be able to see all content in that container because creators always have full control for their content. To prevent this we programmatically change the creator user of newly created content. This is controlled by the Owner of items created by Visitor (OwnerWhenVisitor) field that can be found on content lists (e.g. item lists, libraries and forms). By default this is the Admin user but you can freely change this to a user of your choice.