Enhance UX and add features to the Callback pages

[whabanks]

Summary | Résumé

This PR contains UX and feature enhancements to the callbacks pages.

• Additional validation:
  1. That the URL entered is valid (is https:// and passes the URL format check in validators)
  2. That the URL is reachable and returns http 200 by performing a small ping to their callback service
• Instead of clearing the form and saving to delete a callback config, a dedicated delete link is now available with a confirmation prompt before deletion
• A "Test response time" button was added so users can easily gauge how long their service takes to respond
• Footer form controls are sticky, so users do not need to scroll down to the bottom of the page to test response times.

Test instructions | Instructions pour tester la modification

1. Create a temporary callback url: https://webhook.site/ or https://beeceptor.com/
2. Navigate to the api callbacks page

New validation

Test 1 - Valid callback

1. Use the URL you created earlier and create an API callback
2. Note that when you save a callback configuration a message with the response time is included
3. Send some notifications and make sure callbacks are working

Test 2 - Invalid URL

1. Use the URL you created earlier but make it http:// instead of https://
2. Note the error message: Enter a URL that starts with https://
3. Note the hint text: Must start with https://

Test 3 - Valid URL but server doesn't exist

1. Modify the callback URL so it points to an invalid endpoint
2. Note the error message: Check your service is running and not using a proxy we cannot access
3. Note the hint text: Your service must be running and reachable from the internet.

Delete button

1. Delete callback you created
2. Note the confirmation message before deletion
3. Note that during confirmation the Submission controls are not present (Save, Test response time, delete)
4. Confirm the deletion
5. Note you are returned to the API page that links to API keys, callbacks, etc.

Test response time button

Test 1 - Button visibility

1. Navigate to the callback config page
2. Note that there is no Test response time button
3. Create a callback again then navigate back to the callback page
4. Note that when returning to the callback config page, the Test response time button is visible

Test 2 - Response time button

1. With a callback configured - click the Test response time button
2. Note the message indicating the response time
3. Note that you aren't taken back to the API integration page but remained on the Callback config page

Test 3 - Differing URLs

1. With a callback already configured - change the URL of the callback but do not click save
2. Test the response time
3. Note that the URL input into the form was tested

Test 4 - Validation

1. All the validation cases from the above tests should also apply to the Test response time button.

Inbound SMS callbacks page

To be able to access the Inbound SMS Callbacks page we first need to enable the Receive inbound SMS setting for the service.

1. Add a row to the inbound_numbers table:

INSERT INTO inbound_numbers (id,"number",provider,service_id,active,created_at,updated_at) VALUES
	 ('2a7b8671-3b71-4ba0-abcf-df880802b0f9' ,'<any phone number>','pinpoint','<your service id',true,'2024-09-09 00:00:00.000',NULL);

2. In the service_permissions add a row to give your service the inbound_sms permission

INSERT INTO service_permissions (service_id,"permission",created_at) VALUES
	 ('<your service id>','inbound_sms','2024-09-09 15:57:18.958');

3. Clear all service-.* keys in Redis
4. Navigate to the service settings and verify that the Receive inbound SMS setting is turned on
5. Navigate back to API integration -> Callbacks
6. Note you can choose between Delivery receipts and Received text messages
7. Choose Received text messages and repeat the validation & test response time button tests to ensure feature parity between the two pages.

[github-actions]

🧪 Review environment

https://7vmedldf7xzv7o4lt64mbxyvzq0gusde.lambda-url.ca-central-1.on.aws/

[whabanks]

Thoughts on testing these validation messages in Cypress, and instead test that we're logging appropriately here?

[andrewleith]

Yeah its a good question. We could definitely test the error messages in Cypress, although you do already have it done here. I think if we were building up this feature from scratch we would probably have created a cypress test suite, but where we are just tacking something on, maybe this is fine?

I like the idea of testing the logging, especially if those logs' formats are tied to other parts of the system like alarms. Testing logging is pretty easy, I had to do it for system status here.

[andrewleith]

So this looks great overall, just the question on if we can actually enforce a particular response at setup time without advising the clients of this in advance.

[andrewleith]

As discussed in slack, this might be an issue since here it expects the callback servers to respond with a 200 when we call them with {"health_check": "true"}. If we want to do this we would probably have to advertise this in the docs so users are aware.

[andrewleith]

Yeah its a good question. We could definitely test the error messages in Cypress, although you do already have it done here. I think if we were building up this feature from scratch we would probably have created a cypress test suite, but where we are just tacking something on, maybe this is fine?

I like the idea of testing the logging, especially if those logs' formats are tied to other parts of the system like alarms. Testing logging is pretty easy, I had to do it for system status here.

[github-actions]

🧪 Review environment

https://h446q5dcbyez4g5lyixah4gn5i0lshdx.lambda-url.ca-central-1.on.aws/

[whabanks]

Just a formatting change here.

[andrewleith]

LGTM - works as expected! Will test some scenarios in staging once its there.

[andrewleith]

I was going to say I was concerned that using the flask global object might leak the value here to other users, but just learned that values stored here are request-specific and last for only one request. Good to know!