Step 2: Approving Features
Step duration ~40 min
Last updated
Step duration ~40 min
Last updated
Users are stored in the system data structure 'App users' (WebUser), and within the 'role' field, we can store roles as a comma-separated list, like 'admin', 'user', 'moderator'.
Role-based security control is established through the following settings:
API-Endpoint Security Layers - Conditions on the user's session, where we can set up conditions based on any fields of the user (from the WebUser object), including roles
Conditions on pages, tabs, sections and actions within object cards.
Let's create a page called 'Tag Management,' which is only accessible to users with the 'admin' role.
We cannot remove an object directly through the API endpoint, as it's designed this way for consistency and security reasons. However, if it's necessary, we can achieve this through scenarios. Here's how:
Add a new field called {{delete}} with a boolean data type
An action on the object card will set this field to true (make sure to specify {{id}}, as failing to do so will result in the creation of a new object)
Run a synchronous scenario that checks the value of the {{delete}} field. If it equals true, the object is deleted.
Let's configure the Features management page. Go to the Web-pages section and create a new page. Next, add four tabs to the page:
Approved features
Suggested features
Released features
Declined features.
Go to the API section and add a new API endpoint for 'Suggested Features.' This endpoint should be available for authorized users with a role such as 'admin'.
Note that the field 'role' can contain several roles separated by commas (e.g., 'admin, moderator, user'). This is why we use the 'like' operator, not the equal operator (=).
Let's add some colors! Objects with 'type' equal to 'bug' should be displayed in red, while objects with 'type' equal to 'feature' should be displayed in green. To do this, go to the configuration of the 'Features' data structure and add a new field named 'color' with a data type of 'color' (string).
Next, we need to create a scenario to populate this new field. Since we already have a scenario for processing all new objects in the 'Features' data structure, we can simply edit it.
If the 'type' is equal to 'bug,' then set the 'color' field to 'e33636' (which represents red in HEX)
Otherwise, set the 'color' field to '1ed627' (which represents green in HEX).
In the configuration of the Cards component, select the .
We create an API endpoint for the "App users" (WebUser) data structure and set the filter to "id == id."
Next, go to the configuration of the Profile web page and add a Form component. Turn on the option for editing objects and use the user's ID.
Next, we'll configure actions in the Cards component. First, let's create an API endpoint for setting the development status, request status, and decline reason.
Then, on each tab on the Feature Management page, we set up Cards with actions:
Actions on the Approved Features tab:
Put back to backlog. feature_status → new, development_status → ; Conditional: development_status == planned
Choose for development. development_status → under_development; Conditional: development_status == planned
Remove from "under development". development_status → planned; Conditional: development_status == under_development
Release. development_status → released; Conditional: development_status == under_development
Remember, if we want to edit an object via an action, we have to specify the object's ID, which is usually taken from the object card.
Actions on the Suggested features tab:
Approve. feature_status → approved, development_status → planned
Decline. feature_status → declined, decline_reason → take from the form
Actions on the Declined features tab:
Put back to Backlog. feature_status → new, decline_reason→
We are creating a new page, and to make it public, we need to override the portal security settings for that specific page:
The page will contain three cards components as columns:
Also, let's set a custom portal appearance and upload a logo page using the File upload structure.
Remember that the API endpoints for that public page should also be public, meaning there shouldn't be any conditions on the user's session.
