What goes in changeset params vs the struct

Questions / Help
, ,
1

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?

2

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
3

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

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
5

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.

6

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

7

@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.