Part of epic #105

What type of user is this for? [volunteer/supervisor/admin/all
supervisor

Where does/should this occur?
system email sent to supervisor

Description
Digest emails should include the following:

• most recent case_contact attempted
• number of successful case_contacts made
• number of unsuccessful case_contacts made

Screenshots
Here is an example of a PG CASA email:

And here are some examples of digest emails:

Related issues
#125, #22

All work related to database & data that lives in it i.e.:

casa_cases
volunteers
case_contacts
case_assignments
database schema changes

Related to the following open issues: #34

remove duplication of login/signin roles in testing

See example below:

Part of epic #3

What type of user is it for? [volunteer/supervisor/admin/all
volunteers

New email text
https://github.com/rubyforgood/casa/blob/master/app/views/volunteer_mailer/deactivation.html.erb

Subject: Your account has been deactivated

Hello [volunteer display name],

Your CASA/Prince George’s County volunteer console account has been deactivated. Should you resume service as a CASA volunteer in the future, your account will be reactivated. Thank you for your service to CASA!

If you have any questions, please contact your most recent Case Supervisor for assistance.

– CASA/Prince George’s County

Related issues
#125, #23

Part of epic #3 (volunteer dashboard) & epic #59 (data)

Currently, volunteers can only input case_contact time value in duration_minutes.

PG CASA would like a volunteer to be able to log case_contact time values in duration_minutes AND duration_hours.

Ex: 1 hr. 15 minutes

Resolution should account for calculating total case_contact durations for reporting purposes.
Ex: When an admin pulls a report of total time spent on case_contacts, that number should look like: 5 hrs 15 minutes not 3 hrs 135 minutes

Some possible ways of handling this:

• two drop down menus: one for duration_minutes and one for duration hours
• user inputs pre-formatted numerical text value (like the way occurred_at is handled)

See here for reference on staging

test issue

Use this? https://github.com/voormedia/rails-erd

All work pertaining to how stuff looks on the front end! Will touch work on epics #3 & #4

Priorities

• make things look nicer (without complicating functionality)
• ensure CASA brand & style are applied to all front end elements
• modular css style guide that can be applied across site. Example of some modular css for Ruby can be found here.

Not priority, but would be nice if you wanna make it happen!

• light graphic design as needed that makes navigation easy and intuitive and on brand.

Open issues related to this epic: #8 #46

relates to epic #38

part of epic #4

What type of user is this for? [volunteer/supervisor/admin/all]
admin

Where does/should this occur?
This should be an addition to the admin dashboard under edit Volunteer.

Description
deactivating a volunteer account means the volunteer can no longer log in. This is not needed for MVP right now but we do need to build it.

related to issues
#22

relates to #28

As a volunteer that is logging a new Case Contact event, I should not see the "other contact type" text box unless "other" is chosen as a Case Contact Type.

As a volunteer, I expect that if "other" is chosen, then the "other contact type" text field is required.

As a volunteer, I expect for the "other contact type" to no longer be visible if I choose "other" and then choose another option in the "case contact type" select.

CASA Volunteer Portal - User Permissions

Permissions by roles (in order of least permissions)

Permission all roles have

• View their own profile
• Edit their own profile

Volunteer

• Create new case_contact for their casa_case
• Edit case_contact details for their casa_case (needs confirmation and details from stakeholders)
• Edit teen_program_eligible for their casa_case
• View case_contact details for all case_contacts they have had with active casa_case. They should not be able to see or edit case_contacts for casa_case that was reassigned to a different volunteer even if they might have created those case_contact records.

Supervisor

🚨 This role exists but the flows associated with this role do not as they are POST MVP 🚨

• volunteers assigned to them, regardless of case assignment status (view and edit)
• case_contacts associated with a supervisor's volunteer assignments (view and edit)
• casa_cases associated with a supervisor's volunteer assignments (view and edit)
• volunteer and case assignments for their volunteers (view and edit)
• generate reports (need more details)

Admin

• generate reports (need more details)
• create new volunteers
• assign supervisors to volunteers
• assign a volunteer to a casa_case
• unassign a volunteer from a casa_case
• should be able to see all data but we might tailor the data shown to the dashboard just for usability purposes
• admin should not be able to create case_contacts and any related objects we might build tied to case_contacts

Currently, the index shows the case contact id. It should be reworked to show the CaseContact.contact_number.

Related to #3

• button to create new_case_contact
  • button leads to new_case_contact path (#28
• infinite previous case contacts
  • should pull all information from previous case_contact including:
    • date, case_contact type, time duration
  • sorted by newest at the top

***only case_contacts from active casa_case_assignments should display in the volunteer view.

Part of epic #4 (Admin Dashboard)

What type of user is this for? [volunteer/supervisor/admin/all]
This feature is for admins and should not change what non-admins can see or do.

Where does/should this occur?
Currently, in the admin view/edit case view, admins only see case info.

Description
Add to this view the volunteer/s currently actively assigned to the case. ( case_assignment.is_active == true )
Display volunteer as volunteer name not id or email. If volunteer name is not in the db schema yet, display volunteer email. The volunteer's name (or email) should be a link to the admin view/edit volunteer page.

Screenshots
https://casa-r4g-staging.herokuapp.com/casa_cases/14/edit

If a new casa_case_ can not be created by and admin due to duplicate casa_case_id, Error message should say something like...

New CASA case could not be created because another CASA case already has this ID number.

The user's dashboard is the page you see when first logged in. The route is currently the same for every user (only their permissions are different)

A volunteer should only be able to view the following:

Their own:

• case_contacts & case_contact history [infinite view for now]
• volunteer_name >> double check code naming convention
• volunteer_phone >> double check code naming convention
• volunteer_email >> double check code naming convention
• casa_case_id

Related to #3, volunteers can edit an existing volunteer with the following items:

• name (text)
• phone number (text)
• email (text)

Also we want to display static data:

• start date (date)
• assigned case number (link to the case)

Part of epic: #530

What type of user is this for? [admin/supervisor/volunteer/all]
all

Where does/should this occur

• There is an extra Login button at the bottom of the Login page, which isn't functional - I assume the functional one above came from Devise - which should be removed:
• The Logout button should be updated to match the Login button

Here are the Login buttons:

Here is the Logout button

This issue affects: supervisors

Supervisors should be able to:

1. View ALL volunteers, not just "their" volunteers (because they may need to help out other supervisors) But their default view should be only their volunteers, who they need to supervise)
2. Assign ANY volunteer to ANY case (not just "their" volunteers and cases)
3. Edit a case's "transition aged youth" flag
4. Edit their own name

Supervisors should NOT be able to:

1. edit the names of anyone other than themselves
2. create new volunteers
3. create new casa case

As discussed in the CASA slack channel, I'm going to be implementing Cypress so that Javascript is testable.

As a part of this I would like to:

• programmatically sign in users
• create fixtures for test setup
• convert the current Capybara tests to Cypress tests
• cypress integrated into CI
• README instructions on how to run

Part of epic #3

Where does/should this occur?
On new case_contact creation page for volunteers.

Description
add two optional fields to new case_contact:
miles_driven(integer)
want_driving_reimbursement(boolean)

want_driving_reimbursement cannot be true if there is no value in miles_driven

Relates to #4

Cases -
Index view of all case ids, in order of newest case on top. Should link to a case edit view/popup-type box.
New Case button on top.

Make a UI where an admin can

1. import a csv or paste a list of volunteer emails and names to create volunteers in the system.
2. same for casa cases, with case_number and optional tranistion-aged youth field
3. import list of supervisor-volunteer linkages, supervisor name to volunteer name
4. import list of volunteer-case linkages, volunteer name to case_number

Only Admins should have the ability to create new volunteer and supervisor accounts.

The top of README for devise talks about how it's made with modules and how you can remove modules if you don't want functionality that it provides.

Admins should be able to click on a casa_case from anywhere on the platform and see a show view displaying the following casa_case details:

• casa_case's case_number
• Volunteer email/indentifying info via case_assignment (potentially a list)
  • whether or not this case_assignment is_active
  • case_contacts infinite view by volunteer with rows displaying:
    • case_contact type
    • case_contact duration

'teen program eligible' checkbox can remain

This is part of epic "Admin view" (#4 ). Relates to issue #91 (change volunteer assignment).

What type of user is this for? [volunteer/admin/supervisor/all]
admin

Where does/should this occur?
When an admin is on their dashboard and clicks the "edit" button on a volunteer and are taken to the edit volunteer page

Description
Here, admins should be able to:

• see and edit volunteer display name
• see and edit volunteer email address
• see volunteer start date (date formatted: dd/mm/yyyy)
• see and edit volunteer status to be active or inactive (maybe as a radio button, dropdown, or toggle? Have fun!) - you will need to add this database column
• see a list of cases assigned to the volunteer, with an "edit" link for each which links to the edit case view, and an "unassign" link which unassigns the case from the volunteer
• assign volunteer to new case
• deactivate volunteer account (see issue #204)

Future work (NOT in this issue):

1. At the bottom should be a "View as the volunteer" button. (see #3 for full details on volunteer dash view)

Relates to issues
#21 #22 #204

Part of epic #3 (volunteer dashboard)

other should be removed from the dropdown menu under contact_type when creating a new case_contact

see here for reference on staging

Create style guide that can be applied across system using Modular CSS or bootstrap (or something else not listed here, just be sure to file an ADR describing your decision about this!)

Please reference #38 for colors and fonts.

Related to #38

Part of epic: #105

What type of user is this for? [admin/volunteer/supervisor/all]
Supervisor

Where does/should this occur
On the "edit volunteer" page of Supervisor dashboard (future work not in this issue). (It should be the Supervisor equivalent of this page.)

Description
Supervisors should be able to assign any volunteer to any casa_case, just like admins can.

Screenshots
This is what it should look like.

Relates to issues
#20, #30

This devise documentation could be useful for this functionality.

Filter issues by the label "Admin" to see all work related to this epic.

Context
Post MVP, we are focused on improving the admin user experience by refining core functionalities and adding new features.

Permissions
Admins have the highest level of permissions within a single CASA Org instance.
Admins can:

• create, view, edit, and deactivate accounts
• create, view, and edit case contacts
• import new volunteers, supervisors, and cases
• generate system reports
• customize their CASA Org instance

How to access
Log in to QA using the following credentials:
email: [email protected]
password: 123456

Filter issues by the "Volunteer" label to view all work related to this epic.

Permissions
Volunteers have the lowest level of permissions within a single CASA Org instance, but the volunteer account is the most important user type from a business perspective – the data that volunteers log (case_contacts) are the focal point of the entire platform.

Context
Post MVP, we are focused on improving the volunteer user experience by refining core functionalities and adding new features (and new data points for volunteers to log), including:

• follow up activity per case contact (reference mockups in epic #532)
• the ability to download a partially pre-filled court report template
• the ability to complete new activities, including: submitting a court report, and items on a forthcoming emancipation checklist (tasks related to preparing a foster youth for emancipation from the foster system)

How to access the volunteer dashboard
Log in to QA using the following credentials:
email: [email protected]
password: 123456

As a volunteer, when I edit a case contact, I expect to see the same parameters as in the index entry that I clicked.

Currently, the edit parameters are the default ones.
http://localhost:3000/case_contacts

Make sure to create a feature spec for this!

supervisor cannot deactivate volunteer account (cannot lock volunteer out of login)

@compwron to add deets

Revise .csv formatting to ensure it's compatible with how data should display on the backend post import.

Will do once this is ready to release to CASA.

Related to epic #59

Admin clicks button to create new volunteer.
Password for new account is generated.
Password creation triggers system email notifying admin of password.

We're not sure why volunteer_id needs to be in the join table, seems duplicative but there good be things we're missing!

Main issues this affects are: #27 and #32

See below for files!

Some info on adding a favicon to a site on Ruby here.

Like this: https://github.com/maebeale/mutual-aid/tree/master/doc/architecture/decisions

Relates to #4
Volunteer -
Index view of volunteer names and case number (like: Donald Duck - 12345), in order of newest volunteer on top. Should link to a volunteer edit view/popup-type box.
New Volunteer button on top.

This will have to wait until we know where prod will be 😅

Related to #27 and #3

Source: new_case_contact button

Fields to display on form:

• type (radio button, populated by hard coded options)
• hours (drop down menu that accepts only numbers but allows 15 minute increments. Ex: .15, 1.15, etc)
  • date - (pre-filled with html placeholder: mm/dd/yyyy and default to today's date) (post MVP: include a calendar popup, likely want to refer to a library for this)
• ^^^ will be related to new post MVP issue: research libraries for calendar pop up options.
• submit button [related to new issue to come re: submit button backend stuff]
  • submit redirects to dashboard view