Skip to content

re-introduce custom signup forms [3] #629

@aguestuser

Description

@aguestuser

[stub]

Context

  • realized while blocked playing 2-step email signup path [3] #613 that cusom forms are heavy and we don't actually need them yet, so we ditched them until we do
  • by "heavy" i mean: it is difficult to introduce non-text fields into the schema (like passwords and dropdowns) and difficult to run migrations from the schema that worked for just text fields
  • when groups start asking for different fields in their signup forms or multiple signup forms that allow them to track the source for new signups, then play this

Implementation Notes

  • currently we store a FormInputGroup that has a string field for inputs and required which is stored in postgres as an array (ie: :inputs, :string, array: true, default: [] settings in the original migration)
  • we could changes this to :inputs, :text, default: '[]', but is requires non-trivial backfills and breaks rollbacks
  • instead, i think we should ditch the inputs and required fields altogether and instead introduce a has_many-belongs-to relationship between FormInputGroup and a new class called FormInputGroup
  • where FormInputGroup has the fields type (an enum with possible values: text, textarea, select, password, etc.), attr_name (for the attribute the form field will create), label (for the form label), and, optionally options (if it is a select).
  • this will allow cleaner logic for aliasing and recongizing required fields and will generally be cleaner than trying to do it with hashes
  • it will require slightly rewriting SignupForm.for

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions