Dynamically load data from other forms
Â
Business Problem
There is a business requirement to connect and retrieve data from other forms. This serves the following purposes:
1. Minimizing Hard-Coded Dropdown Values: By fetching data dynamically, it reduces the need to hard-code values for dropdown lists that frequently change or have a large number of options (e.g., Health Authority Hierarchy).
o  Solution flexibility and reduced operations cost: Allowing end users to manage most of the reference data, thus less operational cost (no need for a release).
o  Data Quality: minimizing the data errors by using standard values.
Alignment with Business Process: It ensures that the technology solution aligns with the business process - for instance, linking Financial Reporting to the Budget.
Enhanced user experience and increased efficiency – displaying the latest submission when the users make the appropriate selection for their own area. This eliminates the following steps: search, copy, and share submission with other team members which makes updating the data easier and more efficient.
Currently, the only way to connect and retrieve data from other forms in CHEFS is to use the API Key to make the calls. However, there’s a critical issue with using the API key as it is being exposed on the client side thus introducing a security risk.
To address this security issue, a CHEFS' enhancement was submitted via the Fider website on August 17, 2023. The enhancement aims to allow calling secured APIs. The enhancement request can be found here: Ability to call secured APIs · Common Hosted Form Service Feedback.
Solution Approach
Since the only way right now to communicate (get data) in one form from other from is to use API key of the form we’re getting data from but the problem is that API key doesn’t identify the user in any way, our propose solution is to use preferred_username
property of JWT token of the logged user in the API call header same way we do with API key, so this way we can identify the user by calling SSO API https://api.loginproxy.gov.bc.ca/openapi/swagger#/Users/get__environment__idir_users on a backend in additional middleware we’re going to implement as RLS solution https://bcdevex.atlassian.net/wiki/spaces/CCP/pages/1439694866 , so this way we can determine what rows we need to return. If preferred_username
specified in a header as API call authorization we should apply it for API route GET /forms/${form_id}/submissions
only
JWT tokens
are accessible on CHEFS component level in Calculated Value
, screenshot bellow
Â
Here how this token looks like:
Â
preferred_username
is unique Keycloak user 32 chars token-like
identification, so we can use it same way as API key