feature_app_fcm – Push Notifications for the Mobile App (FCM)
Summary
The “App FCM“ feature enables push notifications to the mobile app. When a user receives a new message in the portal, a push notification can be delivered directly to their mobile devices via the Firebase Cloud Messaging (FCM) service. Users are thereby informed of new messages even when they do not currently have the portal open.
How it works for the user
When the mobile app is used, it registers the respective device with the system so that notifications can be delivered to it. If a new message arrives for the user, a push notification is sent to their registered devices. The notification shows the subject of the message as its title and, as its text, a short note together with the sender (for example “New message from …“). Tapping the notification leads the user to the corresponding message.
Device registration
A user can have several devices registered at once, so that notifications reach all of them. Devices can be registered and deregistered again. To keep the delivery reliable, invalid or no longer reachable device registrations are cleaned up automatically: if messages to a device fail repeatedly, its registration is removed after several unsuccessful attempts.
Multilingual notification text
The introductory text of the notification (such as “New message from“) is available in several languages and is selected according to the user's language. The available texts are configurable, so that the wording and additional languages can be adjusted per project.
Prerequisites and configuration
In addition to activating the feature, a connection to the Firebase Cloud Messaging service must be set up. This requires the corresponding Firebase project details and access data (service account) to be configured. Only then can push notifications actually be sent.
Activation
The feature is disabled by default. When disabled, no push notifications are sent to mobile devices; messages then remain available in the portal as usual. When enabled and correctly configured, users additionally receive push notifications on their registered devices.
feature_compress – Data Compression
Summary
The „Compression“ feature is a technical optimization: when data exceeds a defined size, it is automatically compressed before transfer or storage. This reduces data volume and relieves transfer and storage load – particularly with large form data.
How it works
A size threshold is defined for compression. If an amount of data is below this threshold, it is processed unchanged. If the threshold is exceeded, compression takes effect automatically. The entire process runs in the background and requires no interaction from the user or clerk.
Configuration options
The feature offers two settings:
- Activation of compression (disabled by default).
- Threshold in kilobytes above which compression is applied (default value 1000 KB, i.e. approximately 1 MB). Compression is applied only above this limit.
Activation
The feature is disabled by default and is enabled per project when required. As it is purely technical, nothing changes for users and clerks in terms of operation – it only affects the internal processing of large amounts of data.
feature_debug – Debug Mode
Summary
The “Debug“ feature is a diagnostic aid intended for troubleshooting. When active, additional technical information about the underlying communication with ActaNova is included in the system's responses – in particular when errors occur. This makes it considerably easier to analyse problems in the interaction between portal and ActaNova.
How it works
When the feature is enabled, the responses – above all error responses – are enriched with further details, such as information about the request that was sent, its content, and the user context. Support and development can use this information to trace the cause of an error more quickly, without having to reconstruct it laboriously from separate log files. In normal operation the feature has no visible effect for regular users.
Important note on use
Debug mode is intended exclusively for test and analysis environments. It must never be enabled on a productive system, because the additional details may expose internal information. To make this clear, the system also logs a warning when debug mode is active. Accordingly, the feature is disabled by default.
Activation
The feature is disabled by default and should only be enabled temporarily and deliberately for diagnostic purposes. After the analysis is complete, it should be switched off again.
feature_form_elements_with_editing_overlay – Form Elements with Editing Overlay
Summary
The “Editing Overlay“ feature is aimed at those who design forms. When active, it allows an overlay to be enabled for individual input elements in the form builder (Formgrid). At runtime this overlay presents the value entered by the user in an additional, formatted view.
How it works in the form builder
When the feature is enabled, an additional “Overlay Options“ section appears in the form builder for suitable input elements. There the form designer can activate the option “Show overlay when leaving the field“. In addition, a text can be configured to be shown before and after the entered field value – separately for each configured language. The overlay option is available only for input-type elements (text, number, and property fields).
How it works for the user
If the overlay has been enabled for a field, an overlay is displayed the moment the user leaves that field. It shows the value just entered, embedded between the configured leading and trailing texts. This allows the user's input to be presented in context – for example as a confirming, complete sentence – and gives the user immediate feedback on their entry.
Activation
The feature is disabled by default. When it is disabled, the overlay option is not offered in the form builder at all, and existing forms show no overlay. When it is enabled, the option can be activated per input element as described above.
feature_languages – Languages / Multilingualism
Summary
The „Languages“ feature defines which languages are available in the portal and in the forms. A central list determines the languages in which content is offered and entries can be captured.
How it works for the user
Based on the configured language list, the user can choose between the available languages. Forms and multilingual content are displayed in the selected language; if no translation is available for a text field in the selected language, the system falls back to another configured language. This ensures that a meaningful display is always shown.
Language list and primary language
The available languages are stored as a list, e.g. German, English, French and Italian in their respective country variants (such as „de-CH“, „en-CH“, „fr-CH“, „it-CH“). A primary language is automatically derived from this list: a German variant is preferred, otherwise an English one, otherwise the first language in the list. The primary language serves as the default when no specific language is requested.
Configuration options
The feature offers two settings:
- Activation of the language function (enabled by default).
- Language list – the set of offered languages is freely configurable and defined per project. If no languages are configured, stored default values apply.
Activation
The feature is enabled by default. The language selection follows the configured list; the portal's multilingualism is controlled through it.
feature_load_user_roles_from_acta_nova – Dynamic Roles from ActaNova
Summary
The “Load User Roles from ActaNova“ feature (also referred to as “Dynamic Roles“) allows users to be assigned additional roles that originate directly from the ActaNova specialist application. Alongside the standard role types (such as weak, strong, anonymous, guest and normal), each user can thereby receive further, application-specific roles – for example “Employee of Department xxx“ or “Administrative Administrator“.
How it works
When the feature is active and a user is logged in, the portal retrieves that user's roles from ActaNova. These dynamic roles can then be used to control access: CMS pages can be protected with specific dynamic roles so that only users holding the corresponding role are granted access. In this way, the authorizations maintained in ActaNova take direct effect in the portal.
Availability of the ActaNova service
The roles are queried from ActaNova as the user navigates. To keep the load low, the result is cached temporarily and not requested anew on every single page view. If the ActaNova service is temporarily unavailable and the roles cannot be retrieved, the user is informed by a notice that the service is currently not reachable.
Prerequisites and configuration
In addition to activating the feature, a further configuration step is required: the endpoint from which the user data (metadata) is loaded must be set up accordingly in the connected authentication component (Keycloak plugin). Only then can the dynamic roles be retrieved correctly.
Activation
The feature is disabled by default. When disabled, no roles are loaded from ActaNova and only the standard roles apply. When enabled, the dynamic roles are retrieved and can be used for access control on CMS pages.
feature_onboarding – Onboarding / Initial Registration
Summary
The „Onboarding“ feature ensures that a logged-in user is known in the specialist application (ActaNova) as a person or business partner before using a portal service. If this record is missing, the user is first guided through an onboarding form in which their data is captured.
How it works for the user
When a logged-in user opens a page or application that requires onboarding, the portal checks in the background whether a corresponding person / business-partner record already exists in the ActaNova back end. If this is not the case, the user is automatically redirected to the configured onboarding form to complete their data. If the record already exists, they proceed directly to the desired function.
The originally requested address is carried along during the redirect, so that after completing the onboarding the user is automatically returned to the page they originally intended to open.
Non-authenticated users
No check is performed for anonymous (non-authenticated) requests, because no back-end user can be determined without a login.
Configuration and performance
The address of the onboarding form is stored centrally in the portal settings (language-dependent). If no address is configured, the redirect cannot take place. The check result „person already exists“ is cached so that the back-end query is not triggered again on every page view.
Activation
The feature can be enabled or disabled per project. When disabled, the onboarding check and redirect are omitted entirely.
feature_prefill – Prefilling of Forms
Summary
The „Prefill“ feature ensures that form fields are automatically pre-populated with already known data. Logged-in users therefore do not have to re-enter information that is already available to the system (e.g. master data such as name or address) manually.
How it works for the user
When a logged-in user opens a form, the relevant fields are automatically filled with the existing data. The user can accept the pre-filled values or adjust them if needed. This reduces the effort of filling out forms and lowers the risk of input errors. The prefill also works together with dynamic fields – for example fields that update depending on other entries, or selection lists (dropdowns).
Activation
The feature can be enabled or disabled per project. When disabled, the forms start with empty fields and must be filled out entirely by hand.
feature_servicecatalog – Service Catalog / Service Descriptions
Summary
The „Service Catalog“ feature links the portal's online forms with associated service descriptions. When active, an explanatory detail page can be shown for a form, describing the respective administrative service in more detail.
How it works for the user
A detail-info button is displayed on a form, pointing to the matching service description. Through it, the user reaches a page that explains the associated service in detail – for example prerequisites, procedure, or required documents. This allows citizens to inform themselves about the underlying service before filling out a form.
Display of the detail page
The detail-info button is only shown when two conditions are met: the detail-page function is enabled and a page of the type „Service Description“ exists in the current CMS folder. The button links exactly to this page. If no such page exists, the button remains hidden.
Configuration options
The feature offers several settings:
- Detail pages can be enabled or disabled separately. If the function is switched off, the reference to the service description is not shown, but the service catalog itself remains usable.
- The template used for rendering is configurable (default value „form-detail“).
Activation
The feature is enabled by default. It can be disabled per project; in that case the detail-info button and the link to the service descriptions are omitted.
feature_tos – Terms of Use
Summary
The „Terms of Use“ feature ensures that users must accept the portal's terms of use before they can use it. When the feature is active, consent is requested at the first login and documented permanently.
How it works for the user
When a user logs in for the first time, they are automatically redirected to the terms of use page. Only after actively confirming do they gain access to the remaining portal functions. The consent is stored per user, so the prompt does not appear again on subsequent logins. Anonymous (non-authenticated) requests are not affected by this prompt.
Multilingualism
The terms of use page to be displayed can be configured per language (German, English, French, Italian). The user receives the terms in their selected portal language; if no dedicated page is configured for a language, a stored default page is used instead.
Administration / re-requesting consent
Using an administration tool in the back office, the consent already granted can be reset for all users („Request acceptance of the terms of use again“). This is useful, for example, when the terms of use have changed in substance – all users must then confirm the terms again at their next login.
Activation
The feature can be enabled or disabled per project. When disabled, the terms of use prompt is omitted entirely.