Event Subscription Endpoints - Mostly Completed

TODO Thanks for your review of Event Subscription:

Remove only allowing edit of Subscription when form is published.
Move the Event Subscription on form edit to below where the option is selected otherwise you do not see the panel appear/disappear
Add in events for status change and assignment

Friday March 8, 2024 - The previous fix introduced an issue where the name of the submit button api name has to = submit. I am investigating another fix to not depend on the name of the button to be submit. The following property name is wrong and needs to be submit in order for my code to work.

I have also created some documentation for the behavior fix of the copy submission in:
Expected Behaviour - Copy Submission should override submission state

Friday March 1, 2024 - Pull request fix for the allow edit functionality not calling the event when updating an existing submission that has been saved as a draft. There is a new issue found for the allow copy functionality that will be a bug indicated around setting the submitted boolean back to false.
fix: FORMS-1025 ab#23188 fix chefs event service by jimmyPasta · Pull Request #1295 · bcgov/common-hosted-form-service - The QA is now passed on this ticket from the Unity Side also fixes an issue:

Observations:

The bug is that if you create two forms in a row in Chefs and enable the "event subscription" feature for both forms, then in the second form the event subscription will be already present in the event subscription text fields but you're unable to save.

High Level Purpose: Have CHEFS store endpoint urls/tokens in a postgres table. CHEFS can then have event driven api restful callout endpoints. The initial subscribed event will be for the form_submission. CHEFS will use these endpoints to make restful call outs to approved systems. The ability to create subscriptions will be restricted to government systems.

Background: Transportation built a polling method to pick up form submissions through the use of API calls. It would be easier for government applications to instead subscribe to events where the CHEFS application would call out to the endpoint and pass the data after the event. In the case of form submissions the json of the form would be passed in the body.

Thoughts and concerns (Please add concerns here)
The main concern in building callouts may be around allowing communication external to the Openshift environment. The Grants system will also be hosted in the Openshift environment so communication on the backend api rest calls should be possible but should also maybe consider locking down routes.

Mitigating the endpoint editing to IDIR users only so only users that have created or been given access to the forms.

Design

It looks like the ability to schedule events only is available after the initial form is saved. Add a checkbox to subscribe to events. Have a block on the frontend to allow a drop list of events and the ability to enter the endpoint token and endpoint URL for the event. Right now we only have defined 3 events so maybe just one line per each? Or might need to click add for the drop list for separate row?

Only published forms will be able to edit the event subscription

Security

Lock down the ability to create Subscription end points to only allow IDIR users the ability to save Subscribed Events.

Subscription Events

Several subscription events have been discussed the main events being:

Form Submission
Form Submission Status Change - Assigned / Revise - NOT MVP
Form Assignment - NOT MVP

Stored Data

Tablename: form_subscription

        table.uuid('id').primary();
        table.uuid('formId').references('id').inTable('form').notNullable().index();
        table.string('subscribeEvent');
        table.string('endpointUrl').notNullable();
        table.string('endpointToken').notNullable();
        table.string('key').notNullable();

                  id                  |            formVersionId             |  subscribeEvent  |            endPointUrl            | endPointToken |  Key |    createdBy     |           createdAt           | updatedBy |           updatedAt
--------------------------------------+--------------------------------------+-----------------+---------------------------------------+-----------------+-----------------------------------+---------------+-------------------+-------------------------------+-----------+-------------------------------
 05b52fd1-4c50-4b79-9099-a2cf87b34a8a | cbb49343-52be-4353-9db9-948a9b4a7d95 |  form_submission | https://reqbin.com/echo/post/json | AbCdEf123456  | Authorization | 999-dev-seed-data | 2023-06-21 11:02:12.621903-07 |           | 2023-06-21 11:02:12.621903-07

STRA - Thoughts:

I assume that STRA has been done on the API endpoints already

Passing sensitive data through a web restful request may not be necessary if we just send the notification event solely with the id of the form submission. That way the endpoint would be notified only that an event occurred and then call back to the CHEFS API to retrieve the data.

I am open to discussing this further or creating STRA modifications on the GRANT system if we needed it for the entire form submission data to be passed. Each program area would most likely have it’s own sensitivity needs for what personal information is being passed.

New update to the Form Settings:
We have been making some progress on the event subscription component around subscribing to an endpoint for form submission: Some iterations on connecting to a Business Process Management system called ELSA gave rise to the need to store both the key for the headers as well as the token

Only published forms will be able to edit the event subscription