Skip to content

chore: add ash_admin? flag to context#394

Merged
zachdaniel merged 1 commit intoash-project:mainfrom
flavioescobar:main
Apr 7, 2026
Merged

chore: add ash_admin? flag to context#394
zachdaniel merged 1 commit intoash-project:mainfrom
flavioescobar:main

Conversation

@flavioescobar
Copy link
Copy Markdown
Contributor

This commit adds ash_admin?: true to the context of all AshPhoenix forms so that upstream logic can tell if an action is being called from AshAdmin or not.

While doing so, I noticed that all three form calls (for_create/3, for_update/3, and for_destroy/3) were using the exact same options, so I refactored them into a shared variable. I hope this is OK, but I can roll these changes back and only add the new flag if you prefer.

Contributor checklist

Leave anything that you believe does not apply unchecked.

  • I accept the AI Policy, or AI was not used in the creation of this PR.
    • AI was not used.
  • Bug fixes include regression tests
  • Chores
  • Documentation changes
  • Features include unit/acceptance tests
  • Refactoring
  • Update dependencies

Comment on lines +2746 to +2754
form_opts = [
actor: socket.assigns[:actor],
authorize?: socket.assigns[:authorizing],
context: %{ash_admin?: true},
domain: socket.assigns.domain,
forms: auto_forms,
tenant: socket.assigns[:tenant],
transform_errors: transform_errors
]
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While adding context: %{ash_admin?: true}, noticed all three forms below used the exact same options, so I refactored the code a bit to reduce repetition.

Please let me know if this is OK or I should undo that.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me 😄 I believe there are some other cases where we make forms, there should be one for generic actions and one where we build a form for a read action.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should do those as well 😄

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zachdaniel Done! Please check again.

@flavioescobar
Copy link
Copy Markdown
Contributor Author

@zachdaniel I have a feeling we should also add some documentation about this somewhere.

## Action Context

AshAdmin adds `ash_admin?: true` to the context of all AshPhoenix forms it uses (read, update, and
generic actions). You can find this flag in the `source_context` in the context of each action.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't be so specific here. Where you find this actually kind of depends. i.e changeset.context and context.source_context etc. depending. We can point to the Ash core context guide perhaps?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made it less specific. Hope that works.

This commit adds `ash_admin?: true` to the context of all AshPhoenix
forms so that upstream logic can tell if an action is being called from
AshAdmin or not.

While doing so, I noticed that all three form calls (`for_create/3`,
`for_update/3`, and `for_destroy/3`) were using the exact same options,
so I refactored them into a shared variable.
@zachdaniel zachdaniel merged commit 7b7e610 into ash-project:main Apr 7, 2026
22 of 23 checks passed
@zachdaniel
Copy link
Copy Markdown
Contributor

🚀 Thank you for your contribution! 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants