Mike Knoll did some work on this previously. As part of his research, Knoll said that websockets are not secure so they should only be used to tell the client something needs to be updated. Possibly passing the APD_ID of the APD that changed or just re-fetching all the APDs.
We need to set up the application to use websockets. The server should emit a message to users in the same state whenever an APD name, FFY, lasted edited at, last edited by, locked at, or locked by are updated. The server should also emit a message to users in the same state when an APD is added or removed. The server should probably emit different types of messages for add/edit/remove so that different actions can be taken by the client.
The client should join the websocket group for their state to listen for changes to their APDs. The dashboard should fetch the changes when the message is emitted.
[ ] the client joins the websocket server group for their state
[ ] changes to fields visible on the APD List, adding an APD, removing an APD, locking an APD should cause the server to emit a changed message to the client
[ ] the data should update with the new values
[ ] the UI should highlight the changed area to indicate that something changed
Testing criteria
Given
When
Then
Covered
a user for state X
navigating to the APD List page
they are subscribed to the group for state X
the APD List page
another user adds an APD in state X
the client receives the message, gets the new info, adds it to the list, and highlights the new APD
the APD List page
another user edits an APD in state X(fields visible on the page; APD Name, FFYs, and time of last edit)
the clients receives the messages, gets the updated info, updates the item in the list and highlights it
the APD List page
another user deletes an APD in state X
the client receives the message, removes the item from the list
the APD List page
another user opens an APD in state X
the client receive the message, updates the locked information and highlights it
Description and related issues
Mike Knoll did some work on this previously. As part of his research, Knoll said that websockets are not secure so they should only be used to tell the client something needs to be updated. Possibly passing the APD_ID of the APD that changed or just re-fetching all the APDs.
We need to set up the application to use websockets. The server should emit a message to users in the same state whenever an APD name, FFY, lasted edited at, last edited by, locked at, or locked by are updated. The server should also emit a message to users in the same state when an APD is added or removed. The server should probably emit different types of messages for add/edit/remove so that different actions can be taken by the client.
The client should join the websocket group for their state to listen for changes to their APDs. The dashboard should fetch the changes when the message is emitted.
The list should highlight to indicate that something changed and draw the attention of the user. Using something like this https://images.zenhubusercontent.com/113234315/f0a359a2-4bb8-4191-a97e-a7cdcdb92c0b/screen_recording_2023_03_30_at_11_43_11_am.mov
Mockups or link to Figma
Design ticket #4016 https://www.figma.com/file/hJpKHKU6fz5J0Z7fisSwa2/eAPD-MMIS-2022?node-id=4314-19558&t=76z51mQyJdLBO7BR-0
Locking indicator: https://www.figma.com/file/hJpKHKU6fz5J0Z7fisSwa2/eAPD-MMIS-2022?node-id=5628%3A22542&t=COWHWEvjG4Ksdv6G-1
Unlocking indicator: https://www.figma.com/file/hJpKHKU6fz5J0Z7fisSwa2/eAPD-MMIS-2022?node-id=5628%3A22326&t=COWHWEvjG4Ksdv6G-1
Acceptance criteria
Testing criteria