In Dawiso, relations are a fundamental feature. These include object relations (connections between objects) and user relations (associations between users and objects).
- Object relations define how objects are linked and whether these connections assigned automatically or manually
- User relations allow users to be assigned to objects, with the option to control permissions based on workflow states (covered in 8. Optional: Create Custom Assets).
Predefined Relations in Dawiso’s Core Package
Dawiso provides several predefined relations in its core packages, which you can use without additional setup. Some examples include:
- Object relations:
core#isParentOfcreating a parent-child hierarchical relationship. For more information on parent-child relations, see Define Object Types and Their Relations. - User relations:
core#business_owner: A business owner is the main responsible person for an object. Typically, this role has the highest level of control over the object, including permissions to approve, edit, and manage related workflows.core#steward: A data steward is usually responsible for ensuring data quality and maintaining the object but with more restricted permissions than a business owner.
Why Custom Relations?
While core relations cover many standard use cases, Dawiso allows you to define custom object and user relations to fit your specific application needs. Since these relations are often used in components (e.g., filtering tables, diagrams, and creating select boxes), it is best to define them before moving on to the next steps.
In the screenshot below, you can see how relation types are used and visualized in the UI.
Relation Types
First, let’s look at how to create a relation type using a blank template.
"relationTypes": [
{
"key": "",
"name": "",
"reverseKey": ""
}
],
| Property | Purpose |
|---|---|
key | The unique key of a relation type. This key is referenced mainly in the relations asset (covered in6. Define Relations Between Objects) to specify how object types are related and the nature of their connection. |
name | The name of the relation, displayed in the UI. |
reverseKey | The reverse key assigns the opposite relation type (e.g., is referencing and referenced by). Ensure both relation types are defined and reference each other correctly to maintain consistency Some relations do not have a true opposite. In these cases, the reverseKey should reference the relation itself, e.g.: { "key": "related", "name": "Related", "reverseKey": "related" } |
isOriented | This property determines whether the relation has a defined direction. Any parent-child relations require this property to specify which object is the parent and which is the child. |
features | Features determine the behavior of relation types or how they are displayed. For more information, see the full list of relation type features. |
Example: Recipe Manager Custom Relations
Click here to hide example.According to the diagram of our example app, we will need two custom relations:
- contains and its opposite relation is used in
- recommends
Since parent-child relations are covered by default relations, our custom relations will be created as follows:
"relationTypes": [
{
"key": "contains",
"name": "Contains",
"reverseKey": "used_in",
"features": [
{
"key": "can_be_shown_in_diagram",
"value": true
}
]
},
{
"key": "used_in",
"name": "Is used in",
"reverseKey": "contains"
},
{
"key": "recommends",
"name": "Recommends",
"reverseKey": "recommends"
}
],
User Relation Types
In addition to object relations, you can define custom user relations that assign specific roles or interactions between users and objects. These roles can determine ownership and responsibilities.
It is important to distinguish between user relations and Dawiso user roles:
- Dawiso User Roles are system-wide and define a user’s general permissions, such as Admin, Contributor, or Viewer.
- User Relations allow us to assign specific users to objects, indicating their role for that context (e.g., Data Steward, Business Owner, Recipe Owner). Below, you will find the basic structure for defining user relation types:
"userRelationTypes": [
{
"key": "",
"name": "",
"features": [
{ }
]
}
],| Property | Purpose |
|---|---|
key | The unique key of the user relation type, used to assign the user relation type to object types (covered later in 5. Create Object Types). It can also be used to reference the user relation type in components (covered in the next article, 4. Define Smallest Units: Components). |
name | The name of the user relation type, displayed in the UI next to the corresponding user selection field. |
features | Determines the type and behavior of the user relation type, e.g., setting it as default for the space, or limiting its permissions. For more information, see the full list of user relation features. |
Example: Recipe Manager Custom User Relations
Click here to show the example.
For our example app, we need to define two user relation types:
- Recipe Owner (this role includes a feature that automatically assigns the recipe creator as its owner)
- Best Cook
"userRelationTypes": [
{
"key": "recipe_owner",
"name": "Recipe Owner",
"features": [
{
"key": "on_object_creation_is_creator_auto_assigned",
"value": true
}
]
},
{
"key": "best_cook",
"name": "Best Cook"
}
],