Closed Zrrrpy closed 4 years ago
@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.
Yes! Will send them here in a sec @gmfvpereira
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
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:
This looks right to me! @compwron does this accurately reflect what we discussed yesterday?
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?
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!
^^ confirmed with @compwron that the visualization above is accurate.
Not the best UX, but good enough for a first pass.
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 withcase_contacts
vary from CASA Org to CASA Org. Giving admins the ability to addcontact_types
associated with their unique Org instance will increase accuracy in reporting. Groupingcontact_types
will help paint a higher level picture of whichcontact_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
andcontact_groups
associated withcase_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)