A project serving Community Education Partnerships - https://www.cep.ngo/ . This Rails application presents an admin interface for CEP to manage their volunteers and students. And provides a GraphQL backend for https://github.com/rubyforgood/inkind-volunteer .
As an admin, I need to categorize where support tickets come from so that they can be followed up on accordingly.
Things to Consider
There are currently 2 ways to generate support tickets, but there will be three ways. Here are those ways:
Via filling out a survey in the volunteer app, and opting into the feedback option.
Via the admin interface, by clicking "Add Ticket"
(pending) Via filling out a contact information change from the volunteer app. This DOES change the volunteer db stored data, but will need to ALSO generate a support ticket so that CEP knows to update the volunteers contact info in their Volgistics DB.
Analyzing support ticket data means we need to make a clear delineation between these types of ticket creations.
Note: Support Tickets generated from the survey flow in the volunteer app will/should be getting a survey_response_id attached to them.
Criteria for Completion
[ ] Add a "ticket_type" (or something similar, but not type because that's a magic column name for Rails) to the SupportTicket model
[ ] Default type of survey_response, because we anticipate getting the most from this option.
[ ] Update the Admin interface to generate tickets with the type of admin (or something comparable)
[ ] Add a third enum type of contact_info for the new column (this is Postgres, so it has to be a integer column in the db and not an enum type).
Summary
As an admin, I need to categorize where support tickets come from so that they can be followed up on accordingly.
Things to Consider
There are currently 2 ways to generate support tickets, but there will be three ways. Here are those ways:
Analyzing support ticket data means we need to make a clear delineation between these types of ticket creations.
Note: Support Tickets generated from the survey flow in the volunteer app will/should be getting a
survey_response_idattached to them.Criteria for Completion
typebecause that's a magic column name for Rails) to theSupportTicketmodelsurvey_response, because we anticipate getting the most from this option.admin(or something comparable)contact_infofor the new column (this is Postgres, so it has to be a integer column in the db and not an enum type).