-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(issue and respond to RAIs): Implement post sub actions for issuing and responding to RAIs #197
Conversation
import { CMS_WRITE_ROLES, CognitoUserAttributes } from "../shared-types"; | ||
|
||
export const isCmsWriteUser = (user: CognitoUserAttributes) => { | ||
const userRoles = user["custom:cms-roles"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we group this with the other CMS user utility. I can imagine we'll need more of these down the line for auth checks, and a file per function gets out excessive when they're this little. Looks like we grouped the RAI helpers 👍🏼 seems like a good pattern to continue here as user-helpers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, done. very much agree with this, was too scared to break pattern earlier
thanks
src/services/data/handlers/sink.ts
Outdated
)[] = []; | ||
|
||
const rawArr: any[] = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rawArr
is a pretty vague name, and the any[]
type doesn't help. Can you better declare this based on its purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i actually didn't mean to keep this in... was a dev debug helper thing. removed, thanks
@@ -47,7 +47,7 @@ export const OsFiltering: FC<{ | |||
}, | |||
{ | |||
name: "State", | |||
transform: (data) => data.state, | |||
transform: (data) => data.state ?? "", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a case where we should be using the empty field display? (i.e. "-- --")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, thanks
RaiResponseTransform["rais"][number]["response"]["attachments"] | ||
> = []; | ||
|
||
const presignedUrls: Promise<PreSignedURL>[] = uploadKeys |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is work we've done before for the Medicaid form. We should be refactoring this into reusable code rather than copy/pasting code across files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea i agree. i think once we've got medicaid end to end done, we can pull out everything that works for reuse. I'm shy abot doing that now.
Defer to later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fail to see how "getting medicaid end to end done" will affect the way we handle uploading files, tho...especially when that form has been done and we're now in the part of engineering where we can reuse lots of that work we put in? I think this "build it fast, then clean up later" mentality is fine when you're bouncing from product to product doing quick work, but this is a product we have to support and we're not doing a good job of setting ourselves up for that by copy-pasting identical blocks everywhere in our code. We really need to build in a practice to our team where we discuss approaches to these kinds of things so we can save ourselves time and mess.
for each of the attachment types on the{" "} | ||
{ | ||
<Link | ||
to="/faq/#medicaid-spa-attachments" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Linking to medicaid spa attachments won't help :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, thanks. updated
</Alert> | ||
) : null} | ||
{form.formState.isSubmitting ? ( | ||
<div className="p-4"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure you need the extra markup here. You should be able to just do {form.formState.isSubmitting && <LoadingSpinner />}
, no div and no else condition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spot on, good find. done, thanks.
/> | ||
<Modal | ||
open={errorModalIsOpen} | ||
onAccept={() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a consistent Error handling pattern but we need one. I don't think this is the way, honestly. The copy will inevitably send droves of users to the helpdesk when we could probably just communicate there was a network issue or that our servers are at fault.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ya i looked, we have an api error ticket, to make a more global approach. defer to then.
@@ -41,6 +41,7 @@ export const TABLE_COLUMNS = (props?: { | |||
{ | |||
field: "actionType.keyword", | |||
label: "Action Type", | |||
visible: false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to keep the row but hide it, or legitimately remove the rows. I don't believe action type or source are available columns in current OneMAC spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
keep but hide
🎉 This PR is included in version 1.5.0-val.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Purpose
This changeset adds support for Issuing and RAI and Responding to an RAI.
Linked Issues to Close
https://qmacbis.atlassian.net/browse/OY2-26062
https://qmacbis.atlassian.net/browse/OY2-25561
https://qmacbis.atlassian.net/browse/OY2-26268
https://qmacbis.atlassian.net/browse/OY2-26267
Approach
Issuing and responding to an RAI have very similiar forms at the moment, although their separation for now is wise, I think.
The ability to issue or respond to an RAI is guarded by the getPackageActions api logic, which is used both on the frontend and then checked again on the backend.
rai data in the 'main' index is now stored under an 'rais' key. the structure within that key is shaped as
So each RAI object, identified and keyed off its requested timestamp, contains top level timestamps as gotten from Seatool, as well as response and request metadata, as gotten from the mako kafka topic.
Using this structure, along with turning indexing 'off' for the rais field, we're able to easily marry the seatool data about rais to the mako counterpart, and make that data available to the app.
Currently, we're showing RAI Activity at the bottom of the page. Theres a row for each RAI thats occurred. They're enumerated in increasing order, and it shows the latest status of that RAI.
Other things fixed:
Assorted Notes/Considerations/Learning
We will undoubtedly change how we show and present this RAI data. Screens and finer detail is being worked out, but this should be a good starting point. I think this PR shows what data is available and how its organized. So, I submit this as a place to start.