Not respecting disabled JSON API resources

Disabling resource types is a feature of JsonApi Extras not jsonapi alone.

However that being said, I think its important to check. I believe jsonapi extras does this by swapping out the resource repository service. As a result the failed test are likely due to some loose dependency on the extras module for this to work properly. The correct option is probably to check for the alternate service, and then make the check for disabled entries.

Ultimately, we should be relying on the repository to tell us what entity types are valid, and it should be doing the filtering not the openapi module. However i know the jsonapi maintainers have been hesitant to let us depend on the service as it is internal and possibly subject to change in the future.

I can take a look at exactly why the tests failed later this week. Until then any thoughts on how best to implement this?

Ultimately, we should be relying on the repository to tell us what entity types are valid, and it should be doing the filtering not the openapi module. However i know the jsonapi maintainers have been hesitant to let us depend on the service as it is internal and possibly subject to change in the future.

JSON API Extras does this in \Drupal\jsonapi_extras\ResourceType\ConfigurableResourceType::__construct():

  public function __construct($entity_type_id, $bundle, $deserialization_target_class, JsonapiResourceConfig $resource_config, ResourceFieldEnhancerManager $enhancer_manager, ConfigFactoryInterface $config_factory) {
    parent::__construct(
      $entity_type_id,
      $bundle,
      $deserialization_target_class,
      (bool) $resource_config->get('disabled')
    );

Note that last line. That's causing \Drupal\jsonapi\ResourceType\ResourceType::__construct() to be called with $internal TRUE|FALSE.

Which means that both for JSON API and JSON API Extras, you are able to rely on ResourceType::isInternal() to determine this. That's also what \Drupal\jsonapi\Routing\Routes::getRoutesForResourceType() uses to NOT generate routes for internal resource types:

    // Internal resources have no routes.
    if ($resource_type->isInternal()) {
      return new RouteCollection();
    }

At this point, I think it's highly probable that this will continue to work like that for a long time to come.

IOW: good news 😀

AFAICT this actually needs to be solved in Schemata, not OpenAPI. See #2882269: Support for JSON API's ResourceType::getPublicName() and ResourceType::isFieldEnabled(), with a patch that fixes similar problems, and #2967572: Small inaccuracies for JSON API schemas, which landed earlier today.

Taking a look at the patch in #2882269: Support for JSON API's ResourceType::getPublicName() and ResourceType::isFieldEnabled(), I think there are aspects which could be improved by handler this there, but I don't think it would fully solve the issue, since OpenAPI does request each definition from schemata, however, it is a start at least for getting this moved forward.

Hello,

I was working on this issue, but i didn't notice this patch, however i've come up with implementation for this issue using the already existing "exclude" in the options array in JsonApiGenerator.

So basically what i did is loading the jsonapi_resource_config entities (json:api extras only creates a new entity for the overridden resource so here we are loading only the overridden ones, then we check if they are disabled or not to push them into the exclude array.

Updated the patch to apply for the latest dev

Patch for OpenAPI 8.x-1.0-beta3

Patch #11 will work with OpenAPI 8.x-1.0-beta4
2982692-11.patch

@RajabNatshah,

I believe this issue was already resolved in another patch (#3000458: Exclude disabled JSON API resources). Can you test the lastest dev, and confirm if this patch is still need?

Please reopen this issue if the disabled resources are still leaking through.

Noted;
Thank you Rich for letting me know