What goes in changeset params vs the struct

You could expose multiple changeset handling functions. One which allows (a.k.a. casts) the roles, one which doesn’t. Schema.changeset/2 is only special in that it’s used as default changeset function for cast_assoc / cast_embed, but even these can be changed.

Another option would be using custom changesets for your UI layer (embed schema or even schemaless) and convert the validated data of that changeset into the actual params to pass further down into your system.

Anything from params can be user set. So you’re correct, don’t let the user set role to anything they typed into params.

In your specific example, I would create a function that uses the put_change function to set the role and transform the changeset using pipes.

changeset = 
  |> changeset(%User{}, params)
  |> set_user_role("admin")

Repo.insert! changeset

...

def set_user_role(changeset, role) do
  put_change(changeset, :role, role)
end

Thanks! I like that example of set_user_role

I think I’ll go with this pattern that I copied from somewhere:

def set_role(changeset, role) do
  case changeset do
    %Ecto.Changeset{valid?: true} ->
      put_change(changeset, :role, role)
    _ -> changeset
  end
end

Also I’m going to se the initial role in an insert_changeset function:

def insert_changeset(struct, params) do
  struct
  |> change()
  |> set_role(:member)
  |> changeset(params)
end

This approach lets me keep validate_required[:role]) in my changeset/2 function while not allowing the role to be set directly in changeset/2.

what’s the best way to implement this approach for a case with different roles. Customer role, admin role and staff role for example

@dumadi The set_role/2 that I show above works just fine for multiple roles. If you asking about authorization then that is handled by a different part of the application since it is further reaching and shouldn’t (IMHO) be handled by individual schemas.