Step 2: Approving Features

Step duration ~40 min

Step 2.1: Role-Based Access and Tags Management

8:57

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.

Page Access & Security settings

API-endpoint conditions on user's session

Tags management page

Removing Objects

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.

Step 2.2: Features Management, Cards Colors, Profile

16:31

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.

Checking Field Type

• 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 .

Configure Profile Page

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.

Step 2.3: Configuring Actions in Cards, Status Management

16:45

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:

1. Put back to backlog. feature_status → new, development_status → ; Conditional: development_status == planned

2. Choose for development. development_status → under_development; Conditional: development_status == planned

3. Remove from "under development". development_status → planned; Conditional: development_status == under_development

4. 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.

Example of Action's Automatic fields mapping and Conditionals

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→

Step 2.4: Creating Public Development Roadmap

8:45

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.