Public forms

[tbar0970]

This issue is to discuss the possibility of adding public forms to Jethro.

The basic concept: A Jethro admin can set up forms which the general public can access and submit. These could be for event signup, Sunday check-in, volunteering for rosters etc.

Form responses would be stored in Jethro as a distinct entity. But Jethro would provide the option to match them up to person and family records.

A form could be configured to auto-apply to a matching person/family record (where an immediate match is found). If auto-apply is turned off, or no immediate match is found, the form response is stored ready for a Jethro admin to manually apply it to a person/family.

(Matching done on mobile number and/or email address, perhaps with a family name match also).

The actions that might be performed in response to a form submission:

• add to a group
• set core field
• set custom field
• mark attendace as present
• create a note for action
• other ??

These actions could apply to the matching indvidual, or to all the persons in the family, or just the adults ??

Possible extension: Collecting payment in some way along with form submission,

[s4069b]

I can see many uses for public forms.

A related idea - triggered by covid restrictions where we had limited capacity on Sundays - might be the ability to 'book a spot' (or book a seat). Trick with this one would be the ability to show 'seats remaining' (or spaces remaining).

When we had covid capacity restrictions we used a google form to receive 'bookings' and needed to rely on a bit of additional hack/code to update the form with spaces remaining.

[tbar0970]

To note: Many of the actions mentioned above are available via action plans. We should consider how to manage/exploit this overlap. There's also a similarity with note templates, which allow the setting of a custom field.

[tbar0970]

It might be best if the configuration of a form was driven not by the form's appearance but by the actions to be performed. Rather than saying 'add a checkbox labelled "I volunteer for Bible reading"', the admin would say "allow the user to join [group X]"; Jethro would add a suitable widget to the form, and allow the user to customise its label etc.

[tbar0970]

Extra option: If no existing person matches, create a new person using the form submission

[agoddard77]

Yes I agree this would be a VERY helpful feature.

[s4069b]

we setup a google form to collect parent permission details for kids church / youth group / creche etc. at intervals this gets dowloaded as .csv then changes are made to the headers and then the .csv is imported into Jethro.

It's a bit convoluted BUT a very helpful feature with import is the 'sanity check' - where Jethro displays what it is about to import - and you can go ahead or cancel.

Second helpful feature is that those affected (created or updated) by the import get placed into a group (we made a 'recent import' group).

I suspect one or both those features (sanity check / group to record changed records) would be a helpful addition to external forms.

Perhaps the entry of form data could trigger the existing 'import' feature, and use a 'note requiring action' to tell an admin to login at some point to do a sanity check before applying the changes?

[tbar0970]

I suspect one or both those features (sanity check / group to record changed records) would be a helpful addition to external forms.

Good points. Certainly we'd make sure there's a way to see (maybe in a group) which people have submitted/been updated by a given form.

On the "sanity check" step - it's a tension between precision and efficiency. Maybe we could have an option when configuring the form - "auto apply to matching persons" vs "require manual confirmation before applying to existing persons". In the latter case, an admin comes along and clicks a button on each submission to apply it.

I think we'd want to keep it separate to notes though - they often record pastoral history and would get clogged up with these administrative tasks.

[tbar0970]

Further thinking:

1. When someone is filling in a form, they could be given the option to first authenticate using their member area credentials. That way, Jethro knows exactly who is submitting the form, and can pre-populate fields like email and mobile. This is beneficial because (a) it avoids typos in mobile numbers etc (b) saves time for the submitter (c) submitter can review values and update as necessary.
2. A form submission that doesn't 'auto-apply' would need to be manually processed by an administrator, who would either find an existing person to apply it to, or tell Jethro to create a new person based on the form submission.

[tbar0970]

Different kinds of forms I can think of:

1. Cold contact form - "get in touch with XYZ church"
2. Member commitment form "This year, I can help with rosters A B and C"
3. Details update form "Yes, my mobile number is still XXXXXXXX"
4. Kids/youth signup form "I give permission for my child X to attend kids club. She is allergic to elephants. Call me on XXX if she gets hurt"
5. Event RSVP "Count me in for the ladies' afternoon tea" [extension: And here is my $5 paid via paypal ??]

At some point we have to draw a line and say some forms are too complex for Jethro. Eg complex event regos with different prices and multi-family-member regos.

[tbar0970]

The multi-family-member form is actually a common scenario, for weekends away and kids clubs etc. Once per family you enter emergency contact, medicare card number etc. Per-child you enter medicare IRN, allergies etc.

[simon-KAC]

Hi, just checking in on this request. I would love to have either a) a check-in form from Jethro or b) a way to link Jethro with another kiosk type form (using Google Forms or Jotform or similar.

A Form feature with Jethro would take this system to the next level. :)

[tbar0970]

A form submission that relates to multiple persons in a family is quite a common scenario. For example a kids signup form where you want a person record for the parent who fills in the form, and another person record for the child in the family.

Form fields might be something like person.first_name person.last_name related_person.first_name related_person.last_name

Depending on what matches, Jethro might create a whole new family with two members, or update two members of an existing family, or update one existing person and add another person to their family.

[tbar0970]

A good introductory workflow is probably: If somebody is already logged into the members area and they open the form, autofill their details in the form fields If somebody is not logged in to the members area, the top of the form suggests they log in, but gives them the option to "continue as guest". This would mean, I guess, that the initial form URL is /public/?view=form&formid=123 but it could check if you're already logged in and redirect to /members/?view=form&formid=123

[tbar0970]

The form fields are very similar to existing note templates (see note_template_field table). We can at least re-use a lot of the interface code there. ? Should a note_template be considered a special kind of form, which is submitted on the backend and saved in a note?

The things we would want to do after a form submission is received and matched to a person are basically identical to the actions of an action plan. An easy implementation would be to have the user select an action plan to be executed once a submission is received and matched. But this would be more fiddly for the user to configure. (Currently, action_plan actions are stored in a big serialised array. Better if they were in structured DB records)

[tbar0970]

Work in progress.

• [x] Interface for configuring forms in admin area
• [x] Public page for submitting forms
• [x] View form responses in admin area
• [ ] Logic for matching persons
• [ ] Multi-person matchiing (eg parent and child)
• [ ] Different actions depending on what boxes they tick

[tbar0970]

Possible extension: "Clusters" of form responses. At the bottom of the form is a button "add another response" which gives you another copy of the form to be submitted in tandem. Idea: You could configure whether each field is included in secondary forms or only the primary one. And/or whether to pre-populate the secondary form fields with the values from the first one.

[tbar0970]

Possible extension: ability to email or sms out personalised form urls (containing a hashed personid) in which core fields are pre populated, and there is no need for jethro to work hard to figure out which person should be matched.

We would need to consider the husband/wife sharing email address scenario and make sure they don't get mixed up. And also say "don't forward this email to anyone else"