AE
Ash Elixir•2y ago
Blibs

Create action commits changes even if return fails due to field policy

Hey @Zach Daniel and @barnabasj j, I noticed a behavior that I'm not sure if it is a rbac bug, an Ash bug or if it is not a bug at all and is by design. I have a resource that I forgot to add the fields field policy inside my rbac rules. Because of that, when I run the create action from that resource, it will fail with this error when returning the value: 
[error] FeedbackCupcake.SmartSentences.SmartSentence.read
Policy Breakdown for selecting or loading fields fields: [:category, :sentiment, :male_content, :female_content, :teacher_id] 
  Bypass: Policy | 🔎:
    authorize if: Checks if the actor has the role :admin for field :roles | ? | 🔎
  Policy | â›”:
    forbid if: always true | ✓ | ⛔
[error] FeedbackCupcake.SmartSentences.SmartSentence.read
Policy Breakdown for selecting or loading fields fields: [:category, :sentiment, :male_content, :female_content, :teacher_id] 
  Bypass: Policy | 🔎:
    authorize if: Checks if the actor has the role :admin for field :roles | ? | 🔎
  Policy | â›”:
    forbid if: always true | ✓ | ⛔
This is expected since I don't have a policy for the fields, and adding something like fields [:*] fixes it. The problem is that even if my policy fails as shown above, the create function actually ran correctly, and it did create the row inside the DB. For me this seems odd since I would expect the create and read actions to be inside the same transaction, meaning that if there is a policy error when returning the value, the whole transaction should fail (rollback).
5 Replies
ZachDaniel
ZachDaniel•2y ago
Its the read after the create that is failing, and its not actually possible for us to know before creating it because we don't know the result of the create action.
Blibs
BlibsOP•2y ago
Can't we just have both inside a transaction and do the policy check inside it as-well?
ZachDaniel
ZachDaniel•2y ago
Yes, potentially. I'd need to rework the transaction code after the fact. It does kind of imply a logic issue on your side though, TBH it essentially means that people can create things that they can't see there should be a create policy preventing this from happening, generally
Blibs
BlibsOP•2y ago
That's fair, in the end just adding the field policy fixed it for us. But at the same time it seems counter intuitive that basically all other functionality (like changes, etc) run inside the transaction and if any of them fails, the whole transaction is rolled-back, and at the same time this specific case will have a different behavior.
ZachDaniel
ZachDaniel•2y ago
Yeah, I see what you mean By default read actions aren't run in transactions

Did you find this page helpful?