Unwanted policy logging when using field_policies and an `update` action

My application is configured with config :ash, :policies, log_policy_breakdowns: true. And there is a resource that has field_policies defined. Some fields should only be accessible by an admin user, so the field policies are designed to enforce that restriction.

The problem is that when I run an :update_self action for a non-admin user, there are at least two warning log entries. I don’t want those showing up in the logs for this use case.

The log messages appear to come from the field policies, because they aren’t logged when I allow unrestricted access to all fields.

Here are the field policies:

  field_policies do
    field_policy_bypass @admin_only_fields, {ActiveMemberPolicy, []} do
      authorize_if always()
    end

    field_policy_bypass @member_self_fields, actor_attribute_equals(:__struct__, __MODULE__) do
      authorize_if expr(id == ^actor(:id))
      forbid_if always()
    end

    field_policy @any_member_fields do
      authorize_if {ActiveMemberPolicy, []}
    end
  end

Here’s the update action code:

# :name is a field that can be updated by the actor, if the record _is_ the actor.
attrs = %{name: "New Name"}

member =
  member
  |> Ash.Changeset.new()
  |> Ash.Changeset.for_update(:update_self, attrs, actor: member)
  |> GF.Ash.Api.update!()

And here are the log entries:

12:12:49.195 [warning] GF.Members.Member.update_self
12:12:49.213 [warning] GF.Members.Member.read

In addition, this :self_update action is behind an ash_graphql mutation. The log messages should not appear when that’s called either.

Seems clearly to be some kind of errant logging. It should either be useful or removed. Can you open an issue on the Ash repo? A cursory glance doesn’t point out to me where the issue is, so I will address early next week when I’m back at a computer.

Thanks @zachdaniel, I will investigate this further, then likely open an issue.

1 Like

Something I’m just now noticing is that your code snippet points to you being on 2.x, which is not the code I was looking at earlier. It could be fixed in 3.x. So perhaps looking at the bran 2.0 on ash will point you in the right direction

With the latest fixes to Ash, this is now resolved.

1 Like