Step 2: Approving Features
Step duration ~40 min
Last updated
Was this helpful?
Step duration ~40 min
Last updated
Was this helpful?
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
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)
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'.
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
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:
Conditions on and within object cards.
Run a that checks the value of the {{delete}} field. If it equals true, the object is deleted.
Also, let's set a custom and upload a logo page using the .
