When using content validation with the new options for 'POST_COLLECTION' 'GET_COLLECTION' etc., the documentation does not show the field-list.
Q
A
laminas-api-tools/api-tools-content-validation
1.11.0
laminas-api-tools/api-tools-documentation
1.5.0
Summary
In version 1.5.0 of the content-validation module, the option to define validations for collections and entities separately got included. In version 1.3.0 of the same module, adding validation to the GET-resource was included (with 1.6.0, DELETE as well).
This means, that you can now define a validation for any kind of request.
This changes seems to be no part of the documentation module, which uses the content-validation data to show a list of fields in the Request part of the documentation.
Defining a validation for "POST_COLLECTION" does work on the fetchAll method, but it is not shown in the documentation. Using "POST" does work, but means it includes in both, Entity and Collection.
A better example for this is the GET: We are using parameter like page, page_size, order_by etc. in the GET-parameter for the list, though they make no sense for a sinlge entity. Using just "GET" would show these parameter to both transactions.
Current behavior
No Field list is shown when using "POST_COLLECTION", "PUT_COLLECTION" etc.
How to reproduce
Create a default API with collection GET, POST and, for comparison, entities with GET, POST. This must not implement anything, just be there and be working.
Install the current (today 1.11.0) laminas-api-tools/api-tools-content-validation extention
As you can see, the validator should only work on the collection, but not on the entity.
Call the documentation for the API
=> No field list is visible
Call your api with page=somestringvalue
=> You receive a 400/422 error, as the filter does apply
Change "POST_COLLECTION" to "POST" in the configuration
Refresh the documentation
=> The field list is visible for the collection and the entity as well
=> The page test now works on both collection and entity (which would be correct though)
Expected behavior
When using "POST_COLLECTION", the field list should only be visible for the fetchAll method, where it is also used.
This is true for all other HTTP-methods as well.
Bug Report
When using content validation with the new options for 'POST_COLLECTION' 'GET_COLLECTION' etc., the documentation does not show the field-list.
Summary
In version 1.5.0 of the content-validation module, the option to define validations for collections and entities separately got included. In version 1.3.0 of the same module, adding validation to the GET-resource was included (with 1.6.0, DELETE as well). This means, that you can now define a validation for any kind of request.
This changes seems to be no part of the documentation module, which uses the content-validation data to show a list of fields in the Request part of the documentation. Defining a validation for "POST_COLLECTION" does work on the fetchAll method, but it is not shown in the documentation. Using "POST" does work, but means it includes in both, Entity and Collection. A better example for this is the GET: We are using parameter like page, page_size, order_by etc. in the GET-parameter for the list, though they make no sense for a sinlge entity. Using just "GET" would show these parameter to both transactions.
Current behavior
No Field list is shown when using "POST_COLLECTION", "PUT_COLLECTION" etc.
How to reproduce
'api-tools-content-validation' => [ 'MyAPI' => [ 'POST_COLLECTION' => 'MySpecs', ], ], 'input_filter_specs' => [ 'MySpecs' => [[ 'name' => 'page', 'required' => false, 'field_type' => 'int', 'filters' => [[ 'name' => 'Laminas\Filter\ToInt', 'options' => [], ],], 'validators' => [], 'description' => 'Page of the collection.', 'allow_empty' => true, 'continue_if_empty' => true, ], ]As you can see, the validator should only work on the collection, but not on the entity.
Expected behavior
When using "POST_COLLECTION", the field list should only be visible for the fetchAll method, where it is also used. This is true for all other HTTP-methods as well.