Step 2. Features approving
Step duration ~40 min
8:57
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), includingroles.
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
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 equalstrue, delete the object.
16:31
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 adminNote, 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:
- If
type == bug, the fieldcoloris set toe33636— that is red color in HEX - Else, the field
coloris set to1ed627— that is green color in HEX
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
16:45
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_status→new,development_status→development_status==planned - Choose for development.
development_status→under_development; Conditional:development_status==planned - Remove form "under development".
development_status→planned; Conditional:development_status==under_development - Release.
development_status→released; 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_status→approved,development_status→planned - Decline.
feature_status→declined,decline_reason→ take from the form
- Actions on Declined features tab:
- Put back to Backlog.
feature_status→new,decline_reason→
8:45
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:
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!
Last modified 1yr ago