Skip to content
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

Merged
merged 103 commits into from
Nov 20, 2023

Conversation

mdial89f
Copy link
Contributor

@mdial89f mdial89f commented Nov 16, 2023

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

export interface RaiData {
  [key: number]: {
    requestedDate?: string;
    responseDate?: string;
    withdrawnDate?: string;
    response?: {
      additionalInformation: string;
      submitterName: string | null;
      submitterEmail: string | null;
      attachments: any[] | null; 
    };
    request?: {
      additionalInformation: string;
      submitterName: string | null;
      submitterEmail: string | null;
      attachments: any[] | null;
    };
  };
}

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:

  • Hiding the action type column for spa/chips.
  • Hiding submission source for spa/chips/waivers
  • Fixing the 'delete' functionality when a record is deleted in seatool.

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.

import { CMS_WRITE_ROLES, CognitoUserAttributes } from "../shared-types";

export const isCmsWriteUser = (user: CognitoUserAttributes) => {
const userRoles = user["custom:cms-roles"];

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

Copy link
Contributor Author

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

)[] = [];

const rawArr: any[] = [];

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?

Copy link
Contributor Author

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 ?? "",

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. "-- --")

Copy link
Contributor Author

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

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.

Copy link
Contributor Author

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

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"

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

Copy link
Contributor Author

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">

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.

Copy link
Contributor Author

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={() => {

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea

Copy link
Contributor Author

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,

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keep but hide

@mdial89f mdial89f requested a review from hannasage November 18, 2023 14:07
@mdial89f mdial89f merged commit 03472d1 into master Nov 20, 2023
25 checks passed
Copy link
Contributor

🎉 This PR is included in version 1.5.0-val.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants