Program form overhaul

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.

Future app=PROGRAM, 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, but future INVITE forms will operate in the Involvement universe. Existing invite forms need to be able to create the Involvement, but it's okay if they are unable to pass values forward as described in the next item.

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 Dimension* field types.

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 (that propagate to dimensions, not annotations). 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 before we know we need them.

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 program 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.