Standard patterns for LiveView and changesets (incl embeds)

In https://github.com/OpenFn/Lightning/pull/278 @elias-ba added functionality for validating a "deletion confirmation" modal form, among other things. @stuartc , as the core team grows, I want to make sure we're all aligned on various patterns including:

• how we name and use functions that generate changesets - duplication?
• how validation within changesets should work (see interesting virtual field case below: "scheduled_deletion_email" is a confirmation field, not a real field.)
• how we build changesets for embeds (see #embed-changeset)

I'll schedule some time in the week after the next round of engineers join the core team. and @stuartc , if any of the code in the examples below feels way off we can certainly address it sooner rather than later... it could be a mini refactor later this week or early next.

function naming example

  @doc """
  Returns an `%Ecto.Changeset{}` for changing the user scheduled_deletion.
  ## Examples
      iex> change_scheduled_deletion(user)
      %Ecto.Changeset{data: %User{}}
  """
  def change_scheduled_deletion(user, attrs \\ %{}) do
    User.scheduled_deletion_changeset(user, attrs)
  end

virtual field validation example

@doc """
  A user changeset for changing the scheduled_deletion property.
  """
  def scheduled_deletion_changeset(user, attrs) do
    user
    |> cast(attrs, [:scheduled_deletion])
    |> validate_role_for_deletion()
    |> validate_email_for_deletion(attrs["scheduled_deletion_email"])
  end

embed changeset example

    # Revoke access to projects
    Projects.get_projects_for_user(%User{id: id})
    |> Repo.preload(:project_users)
    |> Enum.each(fn p ->
      Projects.update_project(
        p,
        %{
          "project_users" => %{
            "0" => %{
              "delete" => "true",
              "user_id" => id,
              "id" =>
                Enum.find(p.project_users, fn pu -> pu.user_id == id end)
                |> Map.get(:id)
            }
          }
        }
      )
    end)

Start by reviewing PR #278 and the three examples in this issue: changeset function naming, virtual-field validation, and embedded changesets. Compare the existing patterns and the team’s planned discussion; the work is done when agreed conventions are documented and any follow-up refactors are identified or completed.