This article aims to explain how access permissions can be inherited (from a parent item, to a child item) in Cohero, and how default access permissions differ from Specified access permissions.
1. Basic item hierarchy in Cohero
To do that, it's crucial to understand the hierarchy of items in Cohero. Here is a simplified visual, that explains how the construct works:
From the bottom upwards:
Projects are children of a Space.
Assets are children of a Space.
Spaces are children of a Workspace
A common misconception to address here: Assets are NOT children of Projects. Although a project can be leveraged to perform work on an asset - the asset's parent will always be a Space.
When an item is marked 'Private', it is expected to manage its own access permissions. It no longer inherits default permissions from its parent.
2. Inheritance in two example scenarios
As access permissions tend to be a bit of an abstract topic, let's explain the logic by using 2 concrete scenarios:
2.1 A private & public asset/project in a PUBLIC space
In this scenario, a private Asset was created inside a public Space. Because it's been marked private, regular members of the Space do not automatically have inherited access anymore. It's up to the Asset's creator (or to others who switched it to Private), to decide who to give access to this asset. That can be members of the Space (with the same, or different permissions), it can also be other members from the workspace, or even Guest users.
In this scenario also a public Project was created in this public Space. Note, that when a Space is public - any public items within that space (as in this example, there is a public Project) is giving all Workspace members their default permissions matching their roles (for more info on Roles and their default permissions, see the article: "(All) Roles and Permissions")
2.2 A private & public asset/project in a PRIVATE space
In this scenario, a private Asset was created inside a private Space. Because it's been marked private, regular members of the Space do not automatically have inherited access anymore. It's up to the Asset's creator (or to others who switched it to Private), to decide who to give access to this asset. That can be members of the Space (with the same, or different permissions), it can also be other members from the workspace, or even Guest users.
In this scenario also a public Project was created inside a private Space. As a public item, this project inherits its default permissions from members who have access to the Space (the parent of the project). Meaning: members on a Space level have exactly the same access permissions on the public project. The role on workspace level plays no role in this scenario (because the Space is marked private).
