Skip to main content
Skip table of contents

Access to communication assets

Who can have access to communication assets, and which kind of access is granted, is steered by multiple “dimensions”:

  • domain of the communication asset

  • permission sets assigned to the user

  • asset ownership

A user has access to the communication asset only if all conditions are fulfilled. This article explains what those dimensions are. If you want to check quickly, which communication assets you have access to, you can go straight to the last section.

Domain of the communication asset

Every asset is assigned to a domain (we say “created on a domain”). Which domain it is for communication assets, is set on the system asset. By default, communication assets are created in the domain of their context asset (on which you communicate). It is possible to change this. Please see here for more details.

Exceptions are topics: for them, the domain needs to be configured in the topic asset template.

  • To see a communication item, users must have read access to the domain where the communication asset is created.

  • To add a communication item, users must have write access to the domain where the communication asset is created and be assigned a required permission set as explained in the next section.

  • To edit a communication item, users must have write access to the domain where the communication asset is created

Permission sets for creating (communication) assets

To create communication assets in the respective domain, the following permissions are required:

  • Edit new assets (permission key: asset_checkin_new)

  • Asset relations user (permission key: asset_rel_user)

The required permissions are the same as before the introduction of the domain configuration. Without these permissions, users are shown the message box in the right communication widget in the communication tab: "You have no permission to edit this asset - adding messages is disabled." If a user does not have write access, the communication tab shows the message that adding messages is disabled because of that.

Asset ownership

Asset ownership refers to the fact if the user is an owner of the asset or not.

The user who creates the asset, becomes its owner. Asset ownership may change, but not for communication assets.

For messages, the following applies:

  • asset owners and users with the admin role get full (read and write) access to messages

  • asset non-owners get read-only access to messages

For tasks and markers, the following applies:

  • all users get full access to tasks and markers

In previous censhare versions, owners of communication assets were their creators as well as owners of context assets as the latter were treated as parent assets of communication assets. This influence has been eliminated starting from the current censhare version.

Bringing it all together

Considering all those dimensions, the following applies to the communication assets depending on their type and which kind of access the user have to their domain.

For messages, the following applies:

  • within the domains they have access to,

    • asset owners and users with the admin role get full (read and write) access to messages

    • asset non-owners get read-only access to messages, even if they have a write access to the domain

For tasks and markers, the following applies:

  • within the domains they have access to, all users:

    • get full access to tasks and markers if they have a write access to the domain

    • get read-only access to tasks and markers as they have a read access to the domain

Therefore, if any of your collaborators have troubles with accessing any communication assets, please ask your censhare admin to check this page to understand what causes this problem.

Deprecated behaviour

Previously, the access to communication assets was indirectly influenced by the workflow step of their context asset. We considered this behaviour confusing and removed it starting from the censhare version 2024.1.

However, below you will find a short summary of deprecated behaviour.

What remains: In censhare, assets may have workflows. In some workflows, workflow steps impose access restrictions, to make sure that only designated users are allowed to edit assets on specific workflow steps.

Before censhare 2024.1, communication assets inherited access level from their context asset at the time of their creation. Any changes in the access level to the context asset were not transferred to communication assets, meaning, that when the context asset has been moved to the next workflow step, communication assets were not automatically opened for the users that have access to the context asset on that step.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.