You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Actions represent operations performed on an event record, such as a birth declaration. They determine the resulting state of the record and include, for example, form data submitted to that record.
4
+
5
+
## Core actions
6
+
7
+
Core actions, as the name suggests, are defined within the core and are available for all event types. They often contain specific UI elements or logic. In v2.0, the available core actions are:
The status is applied by the corresponding action.
29
+
30
+
> [!NOTE]
31
+
> Beyond v2.0, we will review which core actions could be removed (and implemented instead as custom actions within our Farajaland configuration). We expect the following actions may be transitioned to custom actions: `VALIDATE`, `REJECT`
32
+
33
+
## Custom actions
34
+
35
+
Custom actions are non-core actions that are defined only in the country configuration using `ActionType.CUSTOM`. All custom actions are “quick actions”, executed via a dialog on the event overview page. They can be configured with flag configurations, action conditionals, and a custom form displayed in the dialog.
36
+
37
+
All custom actions are configurable.
38
+
39
+
<!-- TODO: add screenshot of custom action dialog here -->
40
+
41
+
## Action configurations
42
+
43
+
All custom actions and certain core actions are configurable.
44
+
45
+
Actions are configured on a per–event-type basis, meaning different event types do not share action configurations.
46
+
47
+
Below we describe two configuration options: flag configurations and action conditionals. It is important to note that additional configuration options are available and that many core actions have configuration options specific to their action type.
48
+
49
+
### Flag configurations
50
+
51
+
Flag configurations define flags that should be added to or removed from a record when an action is executed. They can be applied either unconditionally (if no conditionals are specified) or conditionally based on factors such as form data, the role of the executing user, or the record’s current status or flags.
52
+
53
+
**Example:** Adding the flag `approval-required-for-late-registration` when `child.dob` is more than 365 days in the past:
Action conditionals determine whether an action should be visible or enabled based on the record’s status or flags.
68
+
69
+
Action conditionals support two different types of conditional types: `ConditionalType.SHOW` & `ConditionalType.ENABLE`.
70
+
71
+
When executing an action, our backend also checks that the action conditions are met: if `SHOW` or `ENABLE` condition is not met, the backend will return HTTP 409.
72
+
73
+
**Example:** Showing an action only when the record has the approval-required-for-late-registration flag:
Copy file name to clipboardExpand all lines: CHANGELOG.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,17 @@
1
1
# Changelog
2
2
3
+
## 2.0.0 Release Candidate
4
+
5
+
### New features
6
+
7
+
#### HTTP Input
8
+
9
+
HTTP input now accepts `field('..')` references in the HTTP body definition.
10
+
11
+
#### Jurisdiction
12
+
13
+
- Elasticsearch now stores location IDs as a full administrative hierarchy, with the leaf representing the actual event location. This enables searching events by any jurisdiction level (district, province, office, health facility etc.).
0 commit comments