Admins can add contact_types and groups

[Zrrrpy]

Part of epic #4 // relates to issues #815, #816

What type of user is this for? [admin/supervisor/volunteer/all or All CASA Admin] admin

Context contact_types associated with case_contacts vary from CASA Org to CASA Org. Giving admins the ability to add contact_types associated with their unique Org instance will increase accuracy in reporting. Grouping contact_types will help paint a higher level picture of which contact_types are being contacted most and least.

How to access on the frontend in QA: Log in to QA and use these credentials to access the admin dashboard: username – casa_admin1@example.com password – 123456

Where does/should this occur? On the Edit CASA Org page in the admin dashboard.

Frontend Admins should be able to add contact_types and contact_groups associated with case_contacts to be used in their organization's instance and display on create and edit case contact forms.

Backend Current structure: case_contact: … contact_types(arr(str)) Future structure should look something like this: case_contact: … contact_type: casa_org_id, name, group join table (one(case_contact)-to-many(contact_type)): case_contact_contact_type: case_contact_id, contact_type_id uniq(case_contact_id, contact_type_id)

[gmfvpereira]

@Zrrrpy do you know which groups we need to create for the existing contact types?

attorney
bio_parent
court
dss_worker
foster_parent
medical_professional
other_family
other_support_worker
school
social_worker
supervisor
therapist
youth

If you don’t know the groups yet, I can simply add all of them into a single group and we change it later on.

[Zrrrpy]

Yes! Will send them here in a sec @gmfvpereira

[Zrrrpy]

Group: CASA youth supervisor

Group: Biological family bio_parent other_family

Group: Placement foster_parent

Group: Social Services social_worker dss_worker

Group: Legal court attorney

Group: Health medical_professional therapist

Group: Education school

Group: Support Worker other_support_worker

[gmfvpereira]

Future structure should look something like this: case_contact: … contact_type: casa_org_id, name, group join table (one(case_contact)-to-many(contact_type)): case_contact_contact_type: case_contact_id, contact_type_id uniq(case_contact_id, contact_type_id)

I'm not sure I understood the proposed structure with that notation @Zrrrpy

This is what I got, let me know if there's something wrong with it:

[Zrrrpy]

This looks right to me! @compwron does this accurately reflect what we discussed yesterday?

[gmfvpereira]

The way I understood it makes it possible to share a contact_type with different organizations, but looking to https://github.com/rubyforgood/casa/issues/816 makes me think that we may not wanna share contact_types across organizations.

If we end up going with the idea of sharing contact_types across organizations we may need to change #816 to add/edit/update contact types in a page other than the edit page of a specific organization. Maybe adding an "Edit Contact Types" to the dropdown at the top navbar?

@compwron @Zrrrpy thoughts?

[Zrrrpy]

We don't want to share contact_types across different organizations, but rather to give each organization instance the ability to create and use their own unique contact_types (although there will likely be a few default contact_types each organization instance starts with that they can customize, but this is not ticketed out yet.)

Call me on Slack if you want to discuss more!

[Zrrrpy]

^^ confirmed with @compwron that the visualization above is accurate.

[gmfvpereira]

Not the best UX, but good enough for a first pass.