Allow string type in allowed_operators about flop

[woylie]

Hi @patric-vinicios,

Thank you for opening the issue. You mentioned that Elixir is not allowing the conversion of a string field to an atom. That should normally not be an issue. Can you provide more context about this?

Regarding your PR, using String.to_atom can introduce potential risks as it dynamically creates new atoms which aren't garbage-collected. String.to_existing_atom/1 would be the safer alternative here. It would raise an exception if the field doesn't exist as an atom. For that reason, I'm inclined to suggest handling the string-to-atom conversion outside the function. But again, I don't know the context in which you use the function. Could you shed some light on your use case?

[patric-vinicios]

I created a filter that can recevive all the possibles operators. But the client is allowed to send an operator that does not match with an :integer type, for example. That's because the managers asked for a dinamycally filter, where the frontend can send any type of filter in any field.
I need to test if the field is allowed to do that operation, but the problem is, We are using GraphQL (Absinthe), and the field name is sent as a string and the validation in the function is an atom. I tried to do the changes directally in my project, and worked fine as I needed.

Thanks for the advice about String.to_atom. I didn't know about that.

[woylie]

The Flop.validate and Flop.validate_and_run functions cast the filter field as atom and validate the filter operator. And if you want to validate the operator even before you call the query function, you need to call allowed_operators directly, in which case you can convert the string field name to an atom before using the function. If you still think it's not possible, I'd need to see some code, because I still don't understand what you are trying to do.

[patric-vinicios]

def call(entity, params, requested_relationships) do
    case validate_filters(entity, params) do
      true -> return_data(entity, requested_relationships, params)
      false -> {:error, "Operators not allowed for some fields."}
    end
  end

defp validate_filters(entity, %{filters: filters} = _params) do
    result =
      Enum.all?(filters, fn filter ->
        filter.op in Flop.Filter.allowed_operators(entity, filter.field)
      end)
  end

The GraphQL query send the field "name" as a string.

query {
	listUsersBackoffice(params: {
		page: 1
		pageSize: 3
		filters: [
			{
				value: "Sherlock"
				op: "contains"
				field: "name"
			}
		]
	}) {
		data {
			id
			name
		}
	}
}

The call function calls validate_filters. validate_filters compare if the field: "name" has the op "contains".

In this line filter.op in Flop.Filter.allowed_operators(entity, filter.field), filter.field is a String, and the function only allows an atom and return an error.

I want to return to the frontend a list with the errors in which field and what are the allowed operators.

[woylie]

Then this should be sufficient?

defp validate_filters(entity, %{filters: filters} = _params) do
    result =
      Enum.all?(filters, fn filter ->
        filter.op in Flop.Filter.allowed_operators(entity, String.to_existing_atom(filter.field))
      end)
  end

Alternatively, you can rely on the errors that Flop would return. For that, you'd need to define an Absinthe middleware that converts the Flop error format (which is a nested keyword list, similar to what you get when you traverse changeset errors) into a supported error format.

[patric-vinicios]

No, using String.to_existing_atom/1 does not work. It returns an erlang error instead.
Even using the Absinthe middlewares. And the goal is to return a list with the field and its operators allowed, not another error.

[woylie]

But then you're PR doesn't help you either. You just move the function call somewhere else. If you don't want an error to be raised when an invalid field is passed, you need to rescue it.

[patric-vinicios]

This PR resolves my main problem that is: I need to test if the field is allowed to do that operator, for now.
I done it in my deps/flop for a while and I have the error that my team expects for now.
I thought that could be useful to another dev that has the same problem when testing the field and operator using Absinthe.

[woylie]

Again, your PR only moves String.to_existing_atom from your code:

filter.op in Flop.Filter.allowed_operators(entity, String.to_existing_atom(filter.field))

to Flop. And I don't think it belongs there.

[patric-vinicios]

Using String.to_existing_atom/1 raise an erlang error, for some reason. I will study the case, but for now I will not implement the necessary feature in the company API.