Data Model for MVP

[lcreid]

The parent needs the following attributes:

• First, middle, and last name
• Home phone
• Work phone
• Address

Internally we should simply name this model "parent" as "parent_or_guardian" is going to be tedious. I suggest "pog" if we want to retain both concepts, as this is going to be so common in the code that it doesn't really need to be self-documenting.

I'm inclined to think that we should try modelling the parent or guardian as a separate model/table than the user, and just link them. But I'm not sure I have a convincing argument versus just munging it into the User model. It's more like a gut feel that we should separate the concepts. At the very least, it's conceivable that we'd want to keep parent information even when they haven't yet registered for the system.

This is a child of Issue #2 .

[philcarrillo]

As to the model/table name - I would agree that it is would be cleaner if we named this model/table Parent/parents and understand that a "parent" may be a biological parent, a step parent or a guardian. An alternative would be to name this model/table Custodian/custodians as presumably we would only like to include those who had custody of the Funded Person, but perhaps this would sound too much like a fancy janitors convention.

[philcarrillo]

I believe that in the general case, the Parent model should be separate from the User model, unless there was a reason to ensure that each Funded Person only could have one Parent. There should only be one User who is able to add, delete and edit Parent or FundedPerson records. It would cause potential security problems should we have different users (parents) able to edit FundedPerson records.

[philcarrillo]

There will be a many to many relationship between the Parent and FundedPerson models. For each relationship, there would have to be relationship type and we need to define a list of types that would be allowed. We need to confirm whether one Parent or multiple Parent may submit Request for Funding forms as another attribute of the relationship would be whether the Parent was authorized to submit forms.

[philcarrillo]

Since the Parent and FundedPerson do not necessarily reside together, this implies that there should be an Address model and a Phone model.

[philcarrillo]

As discussed, we will initially begin with a simple data model that encompasses only those data elements required to initialize the forms. At the heart of the model are two tables - parents and funded_persons. There may be multiple parent records for any user - user will select the parent from a drop down list. Each parent may have multiple funded persons associated with them.

[philcarrillo]

A preliminary version of the simplified data model has been pulled into the repository and is ready for review:

AutismFundingDataModel_0001.pdf

It is located in the docs folder.

[philcarrillo]

Question on review of the data model - should there be a table parent_funded_person that would allow multiple parents to be associated with the same funded_person?

[lcreid]

The BC ministry treats one of the parents (parents' choice which) as the one that they deal with for funding. We should be able to deal with:

• Both parents seeing all the data and doing everything except actually submitting (i.e. printing) an RTP, amendment to RTP, or any other form that involves spending. Note that I saw nothing that says you couldn't have one parent signing for one child and the other parent signing for the other child
• Only one parent doing anything (e.g. sole-custody cases)
• (I think there would be very few cases like this:) One parent has read-only view of everything, and the other parent does all data modification

I'm inclined to see this as best done via a many-to-many relationship between parents and children, with whatever authorizations are required given to each parent on the relationship.