Add extra auth methods
Currently, auth is done via a pre-defined contributor token unknown-url/#C{contrib_hash}
, which must be either found on the #fragment or entered into a 'password' box. This code identifies the survey, the participant and the role of the contributor.
I would like to optionally offer:
- contact cheksum, contact ID, survey ID (hash?). This would enable a CiviMail link for a contact.
unknown-url/#E{checksum/contact_id/survey_id}
- take a survey ID, and ask for name, email fields, then find-or-create a contact.
unknown-url/#S{survey_id}
And also a policy re finding the participant for a given contact
- require a participant (and use first one) - otherwise: "Sorry."
- find (first) participant and use that, if not found create one.
- always create a new participant and use that.
This would enable non-registered users to submit data.
Situations
-
We want to ask our supporters what they think. Supporters are welcome to make as many submissions as they like.
-
We want to ask our members to vote for something. They're only allowed one submission.
-
We want to poll the public by putting a question on social media. We'll collect names and emails into the CRM as contacts, as well as their responses. We only want to allow one submission per contact. Or, in other situations, we want to allow many per contact.
Security challenges
The multiple sections/pages aproach does not work well here because we rely on a UI that is: present list with view/edit links » edit section/page » save/cancel » back to menu, view/edit another section.
The problem with this is that it requires that people can edit their submissions, which means that previously submitted data is made available. So we absolutely have to know that they are allowed that data; that it is theirs. We can't do this just by asking for their name, email for instance.
So for participants that are not fully authenticated, we must not load existing data, even in situations where we only want one response per contact.
In this situation, we could choose to keep the latest submission only.
- Auth as contributor: can view/edit as they like.
- Auth as contact: can create/view/edit their participant(s). If only one participant/contact allowed, restrict to that.
- Id as new contact: find/create contact, update/create their participant, but do not let any old data out.
Admin UI
Who can make new participants (submissions)
Contacts who have been sent special links:
✔ admins✖ publicAnyone who gives their email, first and last names. Treat as (select: admins|public)
Restrictions
✔ Only one participant allowed per contact.
✔ Updating not allowed.
Contacts, no restriction, updating allowed: show a list of existing participants, with view/edit links. This is a lot of work to implement, and is unlikely to be needed.
Contacts, no restriction, updating not allowed: offer a single-page form, create new participant.
Contacts, 1/contact, updating allowed: load previous data into form, allow saving it.
Contacts, 1/contact, updating not allowed: if previous data exists, just go straight to finish/thanks page.
For non-contacts, new people, then no restriction + updating makes no sense. They can't.
Non-contacts, no restriction, updating not allowed: same as for contacts.
Non-contacts, 1/contact, updating allowed: offer blank form but save over exising, if there is one.
Non-contacts, 1/contact updating not allowed: drop the submission (silently, so we don't reveal that that contact has previously submitted it).
Other considerations
It may be helpful, possibly, to have per-participant setting: this participant is sealed/closed/must not be edited any more. This could be ACL-role based, e.g. public: none|view|edit, like the parts.
I'd prefer to avoid numerical survey IDs. Should introduce random hashes per survey.
-
check checksum works -
check checksum works (CiviMail) -
input errors generate crashes - fix this -
check that the multi create things work