These features are grouped together because they are tightly intertwined.
Note: "Program" here shall mean "Program V2". The zombie Programme V1 need not be touched.
Change Survey.app_name and .purpose_slug to proper EnumFields
As an app name, "Forms", "Forms V2, "Surveys" and "Surveys V2" have been used interchangeably. The official user-visible name is "Surveys V2", but the V2 should not be rubbed in the user's face. "Forms V2" also refers to the underlying machinery that supports point & click editable forms in Program V2. InvolvementApp.FORMS is the enum value referring to this.
Assimilate the InvolvementApp enum into DimensionApp and drop the V2 suffixes everywhere in enum values, value const names and user-visible titles.
For DB fields using these, change them to proper EnumFields. See Involvement.app and .type for reference.
Future purpose=INVITE forms should be in Involvement universe instead of Program universe
We consider fields in this form to be about the program host, not the program item.
This change should be made in a backwards compatible way so that existing forms in existing events continue to function as they currently do in the Program universe, but future INVITE forms will operate in the Involvement universe.
Also DimensionFields in the INVITE forms should propagate dimension values to Involvement. This leads us to…
Change annotation extraction from "extract from these fields:" to "this field passes its value forward to…"
Extracting dimension and annotation values from form responses is a common need in Program V2 and upcoming Volunteers V2 etc. applications. Currently Program V2 implements it in a rather backward way: there is a view where one can define field names the annotation value is extracted from. Let's change this to happen in the form editor itself.
Add "propagate dimension value on create" and "propagate dimension value on edit" checkboxes to DimensionField.
Add "propagate value to annotation" (dropdown of annotations, filtered by "applies to" rules) and "also propagate on edit" to fields that have scalar string, numeric, date or boolean values, excluding Dimension* field types. Survey responses themselves do not have annotations. Hence, when used in the app=FORMS context, this should be hidden. This could be handled via a new prop on SchemaFormEditor such as context="survey"|"program"|"involvement"|… or similar (does this interfere with the React concept of "context"? another word?).
As it depends on the use case to which object these will be passed forward to, the actual implementation of these falls to the workflow. These actions shall update at least the Response dimensions.
- For app=PROGRAM purpose=DEFAULT, a program offer (a Response) that is not accepted yet may be editable, and accepted ones are not; hence, dimension and annotation changes need not propagate to Program at any other moment than acceptance of program offer (creation of Program).
- For app=PROGRAM purpose=FOLLOWUP changes should propagate to Involvement.
- (Future reservation) For app=FORMS purpose=FOLLOWUP changes shoud propagate to the original response in the parent survey as well!
Retain the existing program annotations view, as it can be used to toggle annotations on and off for the event, but remove the "come from" fields and backend machinery for them.
Add a SurveyPurpose.FOLLOWUP to Program V2 forms
In Surveys v2, the intended use of purpose=FOLLOWUP will be asking for more information from people who have responded to a survey. A follow-up survey will share the universe of the parent survey. Let's not implement this yet, but leave a reservation for it.
In Program v2, the intended use of purpose=FOLLOWUP is to ask for more information from people who have been signed up as program hosts in an event. They may first submit program proposals (purpose=DEFAULT), of which some are accepted and some are not. Then, from those program hosts whose program items were accepted, we may need to ask for more personal information.
According to the GDPR, we should not ask for this from people for whom we do not know we need it; hence, we should not ask for eg. special diets (special category under GDPR) just in case.
Profile field selector of a follow-up survey must be a superset of the parent. This allows us to widen the set of selected profile fields using a follow-up survey. For now, just use the form privacy settings and restrict selecting a narrower one, but we may at a later date make this selectable field by field.
Responding to follow-up forms
A follow-up program form can be responded to via URL by anyone who has a PROGRAM_HOST involvement in that event. Create a Workflow for FOLLOWUP in Program V2 and let the workflow decide who can follow up using that Survey.
We should follow SURR (Scope & Use Case Routing) URL scheme here: responding to follow-up forms should be handled by the existing form responding view /<SCOPE>/<SURVEY_ID>.
If the profile field selector of the follow-up is the same as the parent, notify the user they have already consented to processing of their personal data; precedent in editing form responses. If the profile field selector differs (ie. is wider) from the parent, give them the full consent experience.
Follow-up form management
The admin should be able to create and manage follow-up surveys as they can currently manage DEFAULT (program offer) and INVITE forms. They should be able to copy the URL of the survey and view its responses.
Survey.parent and Response.parent
Follow-up surveys in Surveys V2 may eventually refer to their parent surveys with a parent fkey. Responses to follow-up surveys will refer to their parent responses with parent as well. This always needs to point to the newest version of the parent response and hence needs to be updated if parent response is edited. (If the user has multiple responses, they would need to select which response they are following up to.)
Program follow-up surveys with parent=None, universe=involvement are about the program host themselves (not just one program item they are hosting but all of them). Responses to them also have parent=None (they do not refer to a specific program offer).
If we, at a later date, decide we need Program follow-up surveys where responses are tied to a specific program item, we can indicate it with parent=None, universe=program, but at that point we may need to make programs a proper M2M (currently it's just the reverse manager for Program.response). Do not implement this for now.
Viewing Program V2 form responses
Currently, viewing the responses of a program form directs to the program offer view, and there is no dedicated view to view responses to a specific program form. We should make one that has the program admin tabs, and link to it in the program form list in program admin.
These features are grouped together because they are tightly intertwined.
Note: "Program" here shall mean "Program V2". The zombie Programme V1 need not be touched.
Change Survey.app_name and .purpose_slug to proper EnumFields
As an app name, "Forms", "Forms V2, "Surveys" and "Surveys V2" have been used interchangeably. The official user-visible name is "Surveys V2", but the V2 should not be rubbed in the user's face. "Forms V2" also refers to the underlying machinery that supports point & click editable forms in Program V2.
InvolvementApp.FORMSis the enum value referring to this.Assimilate the
InvolvementAppenum intoDimensionAppand drop the V2 suffixes everywhere in enum values, value const names and user-visible titles.For DB fields using these, change them to proper
EnumFields. SeeInvolvement.appand.typefor reference.Future purpose=INVITE forms should be in Involvement universe instead of Program universe
We consider fields in this form to be about the program host, not the program item.
This change should be made in a backwards compatible way so that existing forms in existing events continue to function as they currently do in the Program universe, but future INVITE forms will operate in the Involvement universe.
Also DimensionFields in the INVITE forms should propagate dimension values to Involvement. This leads us to…
Change annotation extraction from "extract from these fields:" to "this field passes its value forward to…"
Extracting dimension and annotation values from form responses is a common need in Program V2 and upcoming Volunteers V2 etc. applications. Currently Program V2 implements it in a rather backward way: there is a view where one can define field names the annotation value is extracted from. Let's change this to happen in the form editor itself.
Add "propagate dimension value on create" and "propagate dimension value on edit" checkboxes to
DimensionField.Add "propagate value to annotation" (dropdown of annotations, filtered by "applies to" rules) and "also propagate on edit" to fields that have scalar string, numeric, date or boolean values, excluding
Dimension*field types. Survey responses themselves do not have annotations. Hence, when used in the app=FORMS context, this should be hidden. This could be handled via a new prop onSchemaFormEditorsuch ascontext="survey"|"program"|"involvement"|…or similar (does this interfere with the React concept of "context"? another word?).As it depends on the use case to which object these will be passed forward to, the actual implementation of these falls to the workflow. These actions shall update at least the Response dimensions.
Retain the existing program annotations view, as it can be used to toggle annotations on and off for the event, but remove the "come from" fields and backend machinery for them.
Add a SurveyPurpose.FOLLOWUP to Program V2 forms
In Surveys v2, the intended use of purpose=FOLLOWUP will be asking for more information from people who have responded to a survey. A follow-up survey will share the universe of the parent survey. Let's not implement this yet, but leave a reservation for it.
In Program v2, the intended use of purpose=FOLLOWUP is to ask for more information from people who have been signed up as program hosts in an event. They may first submit program proposals (purpose=DEFAULT), of which some are accepted and some are not. Then, from those program hosts whose program items were accepted, we may need to ask for more personal information.
According to the GDPR, we should not ask for this from people for whom we do not know we need it; hence, we should not ask for eg. special diets (special category under GDPR) just in case.
Profile field selector of a follow-up survey must be a superset of the parent. This allows us to widen the set of selected profile fields using a follow-up survey. For now, just use the form privacy settings and restrict selecting a narrower one, but we may at a later date make this selectable field by field.
Responding to follow-up forms
A follow-up program form can be responded to via URL by anyone who has a PROGRAM_HOST involvement in that event. Create a Workflow for FOLLOWUP in Program V2 and let the workflow decide who can follow up using that Survey.
We should follow SURR (Scope & Use Case Routing) URL scheme here: responding to follow-up forms should be handled by the existing form responding view
/<SCOPE>/<SURVEY_ID>.If the profile field selector of the follow-up is the same as the parent, notify the user they have already consented to processing of their personal data; precedent in editing form responses. If the profile field selector differs (ie. is wider) from the parent, give them the full consent experience.
Follow-up form management
The admin should be able to create and manage follow-up surveys as they can currently manage DEFAULT (program offer) and INVITE forms. They should be able to copy the URL of the survey and view its responses.
Survey.parent and Response.parent
Follow-up surveys in Surveys V2 may eventually refer to their parent surveys with a
parentfkey. Responses to follow-up surveys will refer to their parent responses withparentas well. This always needs to point to the newest version of the parent response and hence needs to be updated if parent response is edited. (If the user has multiple responses, they would need to select which response they are following up to.)Program follow-up surveys with parent=None, universe=involvement are about the program host themselves (not just one program item they are hosting but all of them). Responses to them also have parent=None (they do not refer to a specific program offer).
If we, at a later date, decide we need Program follow-up surveys where responses are tied to a specific program item, we can indicate it with parent=None, universe=program, but at that point we may need to make
programsa proper M2M (currently it's just the reverse manager for Program.response). Do not implement this for now.Viewing Program V2 form responses
Currently, viewing the responses of a program form directs to the program offer view, and there is no dedicated view to view responses to a specific program form. We should make one that has the program admin tabs, and link to it in the program form list in program admin.