FOM operational support: change FOM status

[MCatherine1994]

Describe the task As required by Julius, need to update the status of one FOM.

Acceptance Criteria

• [x] Update the status of one FOM as required
• [x] Trigger a cache refresh of FOM API (status changes shows up in public will need to refresh cache) Performing a "Start rollout" in OpenShift on fom-prod-api DeploymentConfig is doing the rolling restart, one pod at a time, so should have no impacts to end users.
• [ ] Let Julius verify

Additional context

• Please note that we don't recommend the data change in this way, now is just because FOM is new and just go live, we won't do this in the future.
• Email from Julius

[MCatherine1994]

Updated the workflow_state_code to COMMENT_OPEN for FOM 1444 and FOM 1445

[MCatherine1994]

From Basil:

FYI, I've confirmed the FOM cache only refreshes daily ( @Cron('45 9 * ') // Run at 9:45am UTC each day, shortly after the batch which runs at 9:00am UTC)

I've confirmed that the FOMs 1444, 1445 do NOT show up in FOM public for the default searches, due to the stale cache. These FOM do show up if you search specifically for the FOM id.

Basil did a cache refresh for FOM API. Added to the acceptance criteria so we will remember next time

[ianliuwk1019]

The default search does need a "Start rollout" in OpenShift to refresh the cache (as we saw Basil performed that) or it will be (once a day). (Public only shows up FOM when Commenting-Open). Using other search query as FOM # search will have it shows up (after performing the status fix).

Wondering if we need a feature (is it allowed?) to let only someone with higher privilege staff like Julius to fix this kind of status change issue. @basilv

[basilv]

To clarify further, using other search queries will not necessarily bypass the cache - if that specific search query was performed earlier in the day already, then its results would already be cached.