Passing GraphQL variables to a generic action's arguments

I think your id just needs to go inside the input. What does the generated GraphQL schema for that look like?

like input: %{id: .., input: ...}

But I want the id to be outside of the input, so that it looks and behaves like an update action. Is that possible?

How do I view the generated GraphQL schema?

Stepping back a bit, this is what I’m trying to accomplish:

I need a graphQL mutation that can take either a session user, or a special, single-purpose signed token to authenticate the user. The mutation should take an ID, and an input of map values. One of those map values is the token. I tried to do this with a regular update action, but the read action requires a session user, so that doesn’t work with the token authentication.

You could view it in playground or you could use mix absinthe.schema.sdl Your.Schema to see the full schema. Right now it does not look like we have a way for you to put those action inputs outside of the action, but it is not something that would be hard to add. We would likely call it something like input_location :input_object | :top_level.

For your specific case though you should be able to add identity false in the update mutation to not need the id input generated by default, and read_action :get_by_token_or_id that has arguments that you could use to locate the user.

Okay, then with identity false, and with the read_action :get_by_token_or_id, would the mutation still accept an ID argument?

It should have whatever the arguments are on the read action, so in the read action you could do something like:

argument :id, :string

prepare fn query, _ -> 
  id = 
    if is_token(query.arguments.token) do
      verify_token_and_get_id(query.arguments.token)
    else
      query.arguments.token 
    end

  Ash.Query.filter(query, id == ^id)
end

I’ll give that a shot. Thanks!

That gets us much closer. Here are the actions now:

    read :get_by_token_or_id do
      argument :id, :string, allow_nil?: false
      argument :token, :string
      argument :input, :map

      prepare fn query, _ ->
        dbg(query)
        query
      end
    end

    update :silence_notifications do
      require_atomic? false
      argument :token, :string
      argument :silence_until, :utc_datetime

      change fn changeset, context ->
        token = changeset.arguments.token
        dbg(token)

And here’s the debug output:

[lib/gf/messaging/conversation2.ex:54: GF.Messaging.Conversation2.preparation_0_generated_90FF210C1DDB60A3EB6FCCEDE0E8B59A/2]
query #=> #Ash.Query<
  resource: GF.Messaging.Conversation2,
  tenant: 662830,
  arguments: %{id: "IxLCkOBOkr4PnAZ"},
  filter: #Ash.Filter<id == "IxLCkOBOkr4PnAZ">,
  limit: 1
>

[lib/gf/messaging/conversation2.ex:68: GF.Messaging.Conversation2.change_0_generated_F9B8E45DFA6967330A15B9606FF0286F/2]
token #=> "SFMyNTY.c0VqUmthRVloWXRIbG1KOjIwMjUtMDUtMDRa.mTw3wS0IbepQ2C2u663g8SGylMsMBmBKrD-ZwBduV_8"

The variables passed to the GraphQL mutation are:

          variables: %{
            "id" => conversation.id,
            "input" => %{"silenceUntil" => silence_until, "token" => token}
          }

It looks like the read action doesn’t see any arguments other than :id. However, instead of relying on the read action to provide authorization gatekeeping, the update can do that, I think. Do you see any issues with that?

You can do it with filters on the update action, yes.

  update :silence_notifications do
      require_atomic? false
      argument :id, :string
      argument :token, :string
      argument :silence_until, :utc_datetime

      change fn changeset, context ->
        token = changeset.arguments.token
        dbg(token)
        Ash.Changeset.filter(changeset, ...)