Step 2. Features approving

Step duration ~40 min

Step 2.1. Role based access and tags management

Users are stored in the system data structure App users (WebUser), there in the field role we can store the roles, comma separated, like "admin,user,moderator"
Role based security control is based on the following settings:
  • API-endpoint security layers – conditions on the user's session. There we can set up the conditions on any fields of the user (object from WebUser), including roles.
  • Conditions of the page, tab, section and actions (in object cards);
Let's create a page Tag management, which available only for the users with the role admin.
Page Access & Security settings
API-endpoint conditions on user's session
Tags management page

Removing objects

We cannot remove an object via API-endpoint (due to consistency and security reasons), but if we really want, it is not a problem to do it via scenarios. Here is how:
  • We add new field {{delete}} type of boolean;
  • Action on object card will set that field to true (don't forget to specify {{id}} — otherwise the new object will be created!);
  • We run a synchronic scenario which checks the field {{delete}}, and if it equals true, delete the object.

Step 2.2. Features management, cards colours, profile.

Let's configure Features management page! Go to Web-pages section → Create new page. Add there four tabs:
  • Approved features;
  • Suggested features;
  • Released features;
  • Declined features.
Go to API-section, add new API-endpoint for Suggested features. Endpoint available for authorised users with role like admin
Note, that the field role can contain several roles, comma separated (like admin,moderator,user), that is why we use operator like, not equal =
Let's add some colours! The objects with type == bug should be red, and objects with type == feature should be green. Go to Features data structure configuration and add new field color type of color(string). Then we have to build a scenario for filling that new field. We have got a scenario for processing all new objects in Features data structure, so we can simply edit it:

We check the type field:

  • If type == bug, the field color is set to e33636 — that is red color in HEX
  • Else, the field color is set to 1ed627 — that is green color in HEX
Then, in Cards component configuration we pick the type of colouring:

Configure Profile page

We create API-endpoint for App users (WebUser) data structure, set there Filter id == id:
Then, go to Profile web-page configuration and add there a Form, turn ON the option for editing objects and use user's ID

Step 2.3. Configuring actions in cards, status management

Next, we'll configure actions in Cards. First and foremost let's create an API-endpoint for setting development_status, request_status and decline_reason
Then, on each Tab on Feature management page we setup Cards with actions:
  • Actions on Approved features tab:
    • Put back to backlog. feature_statusnew, development_status ; Conditional: development_status == planned
    • Choose for development. development_statusunder_development; Conditional: development_status == planned
    • Remove form "under development". development_statusplanned; Conditional: development_status == under_development
    • Release. development_statusreleased; Conditional: development_status == under_development
Remember, that if we want to edit an object via an action we have to indicate object's ID (usually taken from the object card)
Example of Action's Automatic fields mapping and Conditionals
  • Actions on Suggested features tab:
    • Approve. feature_statusapproved, development_statusplanned
    • Decline. feature_statusdeclined, decline_reason → take from the form
  • Actions on Declined features tab:
    • Put back to Backlog. feature_statusnew, decline_reason

Step 2.4. Create a public development roadmap

We are creating new page, and to make it public, we should override portal security settings for that particular page:
The page will contain three cards components as columns:
Also, let's set the custom portal appearance and upload a logo page, using File upload structure.
Remember, that API-endpoints for that public page have to be public as well, it means that there shouldn't be any conditions on user's session!