Indeed, those are the only use cases we had in mind for that changeset. For any other cases where you want to change other fields of a user, a separate changeset is the way to go! That’s also why there are separate changesets for confirmation and password change. For an admin interface, you definitely want a custom changeset

I understand it’s normal and expected to have multiple “changeset” helper functions for the different use cases you might have.

Validation is encapsulated in those helpers. If you need to share validations across multiple changeset helpers, create reusable defp validate_foo(changeset, ...) functions (they might group together the validations for one or more fields.

For example, imagine that when an admin creates a user they can set all 10 fields, but if an admin wants to edit a user they are limited to changing 2 fields. The users themselves can edit 6 fields of their accounts, but can never register themselves. This situation I described calls for 3 separate changeset helpers:

• create_changeset
• admin_edit_changeset
• self_edit_changeset

Within each, you only cast and validate the fields that are allowed to change in those specific situations.

Any code that is generated is your code.

Feel free to add new changesets etc.

If you don’t feel comfortable writing this code use an existing library instead.