Parametrize > Client Profiles

[cf7]

SPY staff need the ability to add/edit/delete the input fields themselves, not just client information, so that they can change the database table columns when their intake process or their organization in general eventually changes . . .

Example: SPY staff: "We added this new question to our pre-screen add client page that asks whether the youth are signed up for this new government program or not. So we need to have an extra checkbox there that we can check off for their profile"

Currently, we have the ability to add/edit/delete information, but we have not yet implemented how staff can expand what information can be collected.

[cf7]

Staff have a temporary solution for this: • add a setting to flags that gives staff ability to decide whether that specific flag should appear as an extra demographic or not

[cf7]

Apparently it is not good practice to alter/add/remove tables once the app has reached production. However, staff still need the ability to change what type of data they are collecting.

Perhaps a collection of tables? one that tracks the meta data for the frontend "fields" they want to add, another for holding the actual data, and then a match table to relate the "field" id's to the collected data?

Table 1 - Fields meta data -name of the field -type (stored as a string) -settings for this field (probably for interface uses)

Table 2 - Collected data -string or values that are the actual data input by the user

Table 3 - Match table -matches the id of the frontend "field" to the id of the Collected data

Example:

Field meta data: name , type , settings 'counseling-participation' , 'boolean' , '{ 'input-type': 'checkbox', 'class': 'counseling-checkbox' }'

Collected data: value 'true'

Match data: field_id , collected_data_id 1 , 1

This seems kind of messy though . . .

[bjohnson05]

NOTE: while it's not necessarily a bad thing to have the ability to re-create the database from scratch, you are correct that it's not a good idea to perform that type of activity [like changing the schema] on a "live" database application.

The way you have outlined the "collection of tables" approach is exactly what is called a "relation" [what you're termed your "match table"] in database parlance. If you think back to the "mini-486" class I did in 401, having a special table that relates the two primary keys for two other tables is done all the time. It serves the purpose of providing that relationship, as well as helping to limit (overcome?) the number of many-to-many relationships that exist in the database. It is part of something I did NOT cover in that introduction [due to complexity and time issues] which is known as "normalization".

I hope this helps!