View Submitted Applications and Their Current Status

[klondikemarlen]

Relates to:

• View Submitted applications and their current status student-financial-aid#2
• icefoganalytics/student-financial-aid@main...issue-2/view-submitted-applications-and-their-current-status

Depends on:

• Dev Tooling: Add @/ -> Root Alias Support #15
• Dev Tooling: Add Basic Test Suite Setup To Project #17
• Enhancement: JS Standard Casing From/To Database #19
• Enhancement: Specify Default Schema At Config Level #21

Context

Right now the portal is only displaying items from the application_draft table, but we need to surface data from the application table as well as assessments and other related things.

The API was returning that information previously, but it's been commented out.

We need a landing page for student applications that has details (non-editable), documents related to the application, letters related to the application, funding requests, etc. formatted similarly to the draft screens. An application dashboard of sorts.

@datajohnson will do the screen design and @klondikemarlen can do the wiring and API work.

Concerns

1. There are a lot of "ids" that are being passed around, which are not labeled as such.
   e.g. program: 3
   I believe this will cause a lot inconvenience and confusion in the future.
   It is more predictable to sufix it with "id" if it is an ID field.
   e.g. programId: 3
2. A lot of the data that is being served up might work better if computed in the front-end. Why? Because, if we do it in the back-end, we need to duplicated the conversion process between the draft and application and UI.
3. Many fields that are being returned as a single blob, would be better served as being retrieved from a model specific endpoint. This would vastly reduce code complexity, increase isolation, and speed up data retrieval.

Expected Endpoints and Data Formats

See https://guides.rubyonrails.org/routing.html#crud-verbs-and-actions for a stable example of route naming conventions.

• /api/portal/students/:studentId/applications
  • list format (few fields)
• /api/portal/students/:studentId/applications/:application-id
  • item format (many fields)
• /api/portal/students/:studentId/draft-applications
  • list format (few fields)
• /api/portal/students/:studentId/draft-applications/:draft-application-id
  • item format (many fields)

TODO: it might also be worth making flat URL such as

• /api/portal/applications/:application-id
  TODO: application and draft-application formats should be identical, except for a "type"??? column.

example of list format

{
  "data": [
    {
      "id": 6,
      "studentid": 124479,
      "academicYearId": 2023,
      "createDate": "2023-07-28T19:38:41.000Z",
      "updateDate": "2023-07-28T20:16:15.000Z",
      "isActive": true,
      "submitDate": "2023-07-28T20:16:15.000Z",
      "status": "Submitted",
      "description": "This application was created on July 28, 2023 and last saved 3 days ago."
    }
  ]
}

example of item format

{
  "termsAgree": true,
  "programDetails": {
    "programDuration": "",
    "programName": "",
    "startDate": "",
    "institution": {},
    "yearEntering": "1",
    "startDateOfClasses": "2023-08-02T00:00:00.000Z",
    "institutionId": 2392,
    "studyArea": 618,
    "program": 3,
    "attendance": "Full Time",
    "durationOfProgram": "2",
    "endDateOfClasses": "2024-02-29T20:10:00.000Z"
  },
  "fundingSources": {
    "sources": ["Yukon Grant"],
    "csfaAmounts": "Full amount loans and grants"
  },
  "personalDetails": {
    "firstName": "Marlen",
    "middleName": null,
    "lastName": "Brunner",
    "homeEmail": "klondikemarlen@gmail.com",
    "homePhone": "12342134123",
    "birthDate": "2023-07-28T00:00:00.000Z",
    "sin": "******868",
    "category": 9
  },
  "addresses": {
    "homeAddress1": {
      "first": "asdfsdf",
      "city": 1,
      "region": 3,
      "postal": "Y1A OR1"
    },
    "homeAddress2": {},
    "primary": "Permanent",
    "homeAddress1Id": -1,
    "homeAddress2Id": -1
  },
  "statistical": {
    "language": "French",
    "gender": "Male",
    "disability": "Permanent",
    "maritalStatus": 1,
    "citizenship": 2
  },
  "consent": { "consents": [], "allowOthers": false },
  "residency": {
    "residencyHistory": [
      {
        "start": "2021/05",
        "end": "2023/06",
        "city": 844,
        "province": 3,
        "country": 1,
        "in_school": 1
      }
    ],
    "hasTraveled": 1,
    "lastReturnDate": "2023/08"
  },
  "education": {
    "educationHistory": [{ "leftHighSchool": "2023/02", "school": 310 }]
  },
  "otherFunding": {},
  "studentDependants": { "dependants": [] },
  "csfaAccomodation": {},
  "csfaIncome": { "incomes": [] },
  "csfaExpenses": { "expenses": [] },
  "parents": {},
  "parentDependants": {},
  "spouse": {},
  "documents": {}
}

Data Flow Modeling

How a Draft becomes an Application

NOTE: Students can't edit a submitted application.

Testing Instructions

1. Boot the sfa-client back-end via API_PORT=3100 dev up
2. Boot the student-financial-aid back-end via

cd /src/api
npm run start

3. Boot the student-finanacial-aid front-end via

cd /src/web
npm run start

4. Log in to the app at http://localhost:8080
5. Go to http://localhost:3000/api/portal/students/16442/applications/30243 and check that disbursements are include in the application -> funding requests -> assessments package.
6. Another example student is http://localhost:3000/api/portal/students/250/applications/4299

[klondikemarlen]

I wish I had Sequelize for eager loading: https://sequelize.org/docs/v6/advanced-association-concepts/eager-loading/

[datajohnson]

{ 
 application: {
   id:1235, 
   fundingRequests: [
     { 
       request_type_id: 2,
       ... 
       assessments: [
         {
           id:112, 
           disbursements: []  
         }
       ]
     }
   ]
}

[klondikemarlen]

In the future, it would probably be a good idea to unpack the JSON hear and camelize all the keys.

[klondikemarlen]

See fa52c93

[datajohnson]

It'll be interesting to try out the new controller pattern!

[klondikemarlen]

It'll be interesting to try out the new controller pattern!

Yay! Partially, its about making space for code to grow, but it also provides a standard way to assemble routes, making it easier to identify all available routes.
i.e.

/some-route + action -> maps to -> some-controller.

At some point, I'm going to put a readme in each folder to define the specific boundaries and responsibilities associated with each object type. Mostly I'm just copying from Rails, because what they have works really well at scale.

[klondikemarlen]

If we were using a heavier library than Express we would get these kinds of things for free, so we may want to investigate that avenue at some point.