Add Petition support

[stevejalim]

Following the need to stand up https://github.com/mozmeao/openletter/ and plug it into Basket, there's a desire for a way to achieve the same result in a single service. Specifically we want to have

• Have a main landing page that

  • Displays information about the cause/campaign the petition is for
  • Contains a form to capture the signee's full_name, email, job title and affiliation
  • Shows a list of the current verified signatories
  • Shows a count of the current verified signatories

• Sends an email when someone 'signs', requesting they verify their email address via a unique link

• Records that a signatory has verified their email

• Capture anti-spam/anti-abuse info, incl IP address and user-agent

• Supports marking a signatory in a way that helps us curate the list:

  • approved to signify we're 100% happy the signatory is real
  • boosted for someone significant we want to show early in the list
  • spam for a signatory we think is spam, even if it's somehow validated
    Plus some metadata fields that help us remember why we approved them
  • verified_general for a signatory who was verified via some non-specific means
  • verified_via_socials for a signatory whose social media presence was checked during verification
  • verified_via_research for a signatory who was verified via other research/checking means-

• Allows manual re-sending of verification emails if need be

• Applies role-based access to protect user info appropriately

[stevejalim]

@pmac @robhudson How does this description seem as a first pass at a PetitionPage spec, please?

[robhudson]

Is it possible that the form is configurable per petition? I'm not sure those form fields would work for all forms. I can also see where possibly the signature model may need different fields. But overall this is a great list to get started on.

[stevejalim]

@robhudson We could use wagtailstreamforms to let us customise the fields on a per-petition basis (and so keep the config for a form in the DB, essentially, and we can write something that gathers up all the relevant fields to store as signup. We can also hook in email validation off the back of it.

The blocker in my mind right now is that the wagtailstreamforms library doesn't have formal Wagtail 5.x support, so I don't want to lean too heavily on it just yet. I'll see if i can help make that part happen

[stevejalim]

So, wagtailstreamforms does now have Wagtail 5.x support, but I'm also wondering again about the approach.

I appreciate that we might not always want to collect full name, email, job title and affiliation and/or these might have different labels. That's what led me towards a flexible wagtailstreamforms approach. However, there will be complexity in validating/approving and displaying lists of validated signees etc while operating within the workflows of streamforms.

So, maybe we can go with a core data model that has those four fields, plus fully customisable labels for each, and the boolean option to turn off job title and affiliation if the specific petition didn't need it. If we went with that approach we might be able to using Wagtail core's own Form support (https://docs.wagtail.org/en/stable/reference/contrib/forms/index.html) or just go with a Django model + form that does what we need