[GraphQL] Serialization groups being ignored in embedded relations

[Mellwood1305]

API Platform version(s) affected: 3.0.9

Description
When using serialization groups to define the input/output for graphql, embedded relations are exposed based on their respective serialization groups instead of the groups defined by the root entity of the query/mutation.

How to reproduce
Given the below classes, we intend to expose only the title of the book entity and the name of the author entity. However, this structure will allow me to query for the title of the book entity and all fields on the author entity. The description field on the book entity is not exposed so the group is definitely affecting the Book entity in the query but not the Author entity. Additionally, if I define a standard normalizationContext for the Author, that will be used when querying for Book and accessing the Author relation.

#[ApiProperty(
    graphQlOperations: [
        new Query(
            normalizationContext: [
                'groups' => [
                    'graphql:book:read'
                ]
            ]
        )
    ]
)]
class Book
{
    #[Groups(['graphql:book:read'])
    public string $title;

    public string $description;

    #[Groups(['graphql:book:read'])
    public Author $author;
}

#[ApiResource]
class Author
{
    #[Groups(['graphql:book:read'])]
    public string $name;

    public string $someArbitraryInput;
}

Additional Context
This occurs for all graphql operations REST endpoints are unaffected

[develth]

Do you have someArbitraryInput in your GraphiQL Documentation? Could you provide an Behat Scenario / Test for it?

[alanpoulain]

I think this behavior is wanted for GraphQL since we don't want to generate all possible GraphQL types depending of the normalization context. Has the behavior changed between 2.6 and 3.0?

[Mellwood1305]

Do you have someArbitraryInput in your GraphiQL Documentation? Could you provide an Behat Scenario / Test for it?

Yeah, someArbitraryInput is listed in my GraphiQL documentation in the Book context. If I add a normalization context to the Author (either per route or for the whole resource) then I lose access to everything except the ID. I can do that, I'll respond with it as soon as I can.

I think this behavior is wanted for GraphQL since we don't want to generate all possible GraphQL types depending of the normalization context. Has the behavior changed between 2.6 and 3.0?

I'll have to confirm the behaviour of the operation level normalizationContext in 2.6 but the resource level value previously worked as it currently does for REST endpoints. As in, in the example above, I wouldn't be able to access someArbitraryInput.

If we could only define the "reach" of a query based on the serialization context of the current (Author) entity rather than the root (Book) entity then it becomes difficult to scope the operations effectively and efficiently. For example, Author would have a collection of Books which (in this case) would be exposed in the context of a Book query, meaning I (or anyone with access) could traverse Book > Author > Books > Author etc. Admittedly, I could break this up into separate queries (Book then Author using the IRI) but if I am retrieving a single Book with a single Author it seems a bit frivolous when I could scope the Book item query using a normalization context and return the name of the Author with the details of the Book but not details of the Author that the Book item query should know nothing about.

I'll do some further testing and follow up.

Thanks for the quick response.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[antoninobonumore]

this seems to be still an issue on GraphQl

[soyuka]

imo:

I think this behavior is wanted for GraphQL since we don't want to generate all possible GraphQL types depending of the normalization context.

[soyuka]

reopening but without reproducers/patches this won't move much