[Feature] Architecture for New Application System

DedsecKnight commented 2 years ago

Describe new addition Portal v2 is expected to provide an in-house application system, which allows officers to overcome drawbacks that they are facing due to using Typeform. Right now, it is necessary that the user flow and the high-level architecture is consolidated.

Task List

[x] Look at the database architecture of new application system in the shared drive and provide feedback.
[x] Plan out the user flow and wireframe for mockup.

Additional context

Database Architecture of new application system

abhiamishra commented 2 years ago

Looked over the system architecture + some questions to ask @DedsecKnight
Some issues that exist with preferences as students, in Projects and Research, have to pick their top 3 preferences - must be added to applications DB
In addition, I am talking with Roman to fully flesh out the workflow for conflict of a student applying in multiple projects
A fully fleshed out DB schema should be ready EOD.

abhiamishra commented 2 years ago

Questions for @DedsecKnight

Officer can see other stuffs from other divisions
- Does this just mean applicants that have applied to multiple cohorts or all applicants in general? What is all entailed by "other stuffs"?
Should talk to other directors about how they’re using TypeForm
- Discuss the applicant or application?
What is the use of User ID in the "Junction table between person and application". Aren't entryID and formID sufficient? What new information does userID seek to provide?

abhiamishra commented 2 years ago

Current ERD Diagram

Portalv2

DedsecKnight commented 2 years ago

Officer can see other stuffs from other divisions

I believe this refer to a potential flaw in that design, which basically allows officers to see responses for all applications. In other words, this means that a Project officer can see responses for Research application regardless whether they are affiliated with Research or not. If this is not an issue for other divisions, feel free to ignore it.

Should talk to other directors about how they’re using TypeForm

I believe this has to do with the fact that we need to consult with officers from other division to see what their issues with Typeform Application system are, from which we will know how we can improve it with the new application system.

What is the use of User ID in the "Junction table between person and application".

Junction table represents the Many-to-Many relationship between User and Cohort application, meaning that a user can apply to multiple cohort programs and a cohort program can have multiple applicants. The purpose of User ID is so that we can later fetch all applications that a user submitted to along with the status of each application in Portal view.

Current ERD Diagram

The diagram looks good to me. A few things I think will be needed for it to work with our current database architecture:

The officer object is not tied to the Profile object, which is currently our source of truth for user data on Portal. The easiest way I can think of to fix this is to add profileID field to officer table, which will act as a foreign key referring to Profile object. The schema for Profile object can be found below if necessary:

model Profile {
id               String    @id @default(auto()) @map("_id") @db.ObjectId
firstName        String
lastName         String
email            String    @unique
netid            String    @unique
classStanding    String
major            String
utdStudent       Boolean
roles            String[]
membershipStatus Boolean
membershipTS     DateTime?
resume           Boolean
resumeTS         DateTime?
user User @relation(fields: [userId], references: [id])
userId String             @unique @db.ObjectId
events EventReservation[]
}

Also, in the officer object, an officer can also belong to multiple division, so make sure to take that into consideration as well.