What goes in changeset params vs the struct

I’m not clear on what the best practice is for deciding what can be set from a changeset’s params vs what should be directly set in the struct. I’ve been leaning towards not allowing “important” fields, such as a user’s role (i.e. admin or member) to be set from the params since the params sometimes come directly from the client application. But this sometimes makes different parts of the application need to know how to set the user’s role before calling the changeset. Are there any established best practices (or just plain advice) that anyone can give me?

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.

1 Like

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)
1 Like

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

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

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

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.