Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

openapi_context under xxx_get_subresource not working and wrong default summary #4046

Closed
TheKassaK opened this issue Feb 10, 2021 · 4 comments
Milestone

Comments

@TheKassaK
Copy link

API Platform version(s) affected: 2.6.2

Description

I have a subresource : /api/users/ {id}/basket, so I retrieve the Basket resource belong to the user.

With this yml in users.yml :

        api_users_basket_get_subresource:
            security: "is_granted('CAN_GET_SUB_RESOURCE_USER', _api_normalization_context['subresource_resources'])"
            normalization_context:
                without_permissions: true
                groups: [ "basket:read" ]
            openapi_context:
                summary: 'Retrieve the user Basket'

I cant change the summary, seems like openapi_context is ignored.

The default summary is wrong, for this route I have : Retrieves a User resource. instead of Retrieves a Basket resource.

How to reproduce

use a subresource

@soyuka
Copy link
Member

soyuka commented Feb 10, 2021

#4004 should've fixed that ?

@soyuka soyuka added the bug label Feb 10, 2021
@soyuka soyuka added this to the 2.6.3 milestone Feb 10, 2021
@TheKassaK
Copy link
Author

With this yml it's ok :

basket_get_subresource:
security: "is_granted('CAN_GET_SUB_RESOURCE_USER', _api_normalization_context['subresource_resources'])"
normalization_context:
without_permissions: true
groups: [ "basket:read" ]
openapi_context:
summary: "Retrieve User Basket resources"

So, basket_get_subresource instead of api_users_basket_get_subresource

If I check the route name in a subscriber for example with $request->attributes->get('_route'), I have api_users_basket_get_subresource

So it's weird, and the base problem is the wrong description for subressource operations.

@temp
Copy link

temp commented Feb 17, 2021

Same here. the "api" and $resource-prefix need to be removed to get this working, with is really counter-intuitive, because it looks like it isn't working at all...

@vincentchalamon
Copy link
Contributor

Hi,

The api prefix is a known behavior in Subresources, like many other weird behaviors on Subresources...

We currently working on a refacto of the Subresources (check this out: #2706 and https://github.com/api-platform/core/tree/main/docs/adr) to make them more flexible, more powerful and without those behaviors! :-)

Will be fixed in 2.7/3.0 with the new system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants