Problem/Motivation

Drupal's Webforms are configuration entities.
For some reason each new web-form that is created is creating a new webform_submission bundle by itself under the particular web-form.
The issue is that users in the system can create webforms. As such new bundles will be created and public API will be extended in the long run.

At the moment I want to DISABLE all the things that will be created in future and the only way I can currently think of doing this is from either custom code and resource config decoration and tweaks with config ignore / config_split.

Is there a better way to make that?

Is this a good feature to be added something like a wildcard disable or disable by regex on the global jsonapi_extras settings page.

In reality there is should not be any information disclosure issue, as permissions to view them are not given anyone, but still the API is there and this is still something that will be exposed.

Proposed resolution

Decide on a direction and have it implemented.

Remaining tasks

Direction, patch.

User interface changes

Maybe new config...

API changes

None expected.

Data model changes

None expected. Maybe new config...

Release notes snippet

TBD...

Comments

ndobromirov created an issue. See original summary.

ndobromirov’s picture

ndobromirov commented
Issue summary: View changes
e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

Brainstorming: Since this is controlled by configuration entities, I think the best way to control this is to have custom code that modifies the config entity.

What do you have in mind?

ndobromirov’s picture

ndobromirov commented

My current assumption is the add all of that to config ignore and then start mutating this configs on this environment in ANY way possible. Pretty much the same thing you've mentioned. This will be researched further into how to do that exactly. Current ideas:
- WebForm submissions handling
- Config import / Overwrites api in Drupal somewhere / anywhere.
- JSON:API Extras - decorate the configurable resources repository so I will FORCE them disabled upon reading them into the run-time. Somehow... Maybe add a config to allow for a regex / pattern matching against the resource configs, same as supported by the config ignore (maybe).

Note that I am using the patch with the persistent cache, so whatever the logic will be it should not be that complex and repeated only on cache clear.

I have not yet dived into this in details but likely in the next week or so. It was as a part of a clean-up operation we were doing on the public interface of JSON:API service we expose on the system and this showed up as an edge case.

It is in no way a blocker even if we do not have a solution for it for now.
I've opened the issue, as i had no idea where to start with it even so having pretty much the same idea from your side, there seems to bo not that many options.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Active » Fixed

You could try with a service provider to decorate the resource type. Similar to what JSON:API Extras is doing:

    if ($container->has('jsonapi.resource_type.repository')) {
      // Override the class used for the configurable service.
      $definition = $container->getDefinition('jsonapi.resource_type.repository');
      $definition->setClass(ConfigurableResourceTypeRepository::class);
      // The configurable service expects the entity repository and the enhancer
      // plugin manager.
      $definition->addMethodCall('setEntityRepository', [new Reference('entity.repository')]);
      $definition->addMethodCall('setEnhancerManager', [new Reference('plugin.manager.resource_field_enhancer')]);
      $definition->addMethodCall('setConfigFactory', [new Reference('config.factory')]);
    }

Feel free to re-open if you have more questions / discussion.

ndobromirov’s picture

ndobromirov commented

Hi and thanks for the working example!

Just from curiosity, as this is not decoration, but a complete and hard replacement of the original service.

Why not go with something like standard container decoration?

  # Decorators.
  jsonapi_extras.resource_type.repository:
    class: \Drupal\jsonapi_extras\ResourceType\ConfigurableResourceTypeRepository
    decorates: jsonapi.resource_type.repository
    arguments: ['@jsonapi_extras.resource_type.repository.inner']
    calls:
      - {method: 'setEntityRepository', arguments: ['@entity.repository']}
      - {method: 'setEnhancerManager', arguments: ['@plugin.manager.resource_field_enhancer']}
      - {method: 'setConfigFactory', arguments: ['@config.factory']}

The main reasons I see is that the methods needed by the config repository to overwrite are all protected ones, so this is an enforced limitation from jsonapi module lacking a propper public API :(

Are there other reasons having it implemented that way initially?

This is not a scalable decoration, as decoration should work on the public interface of the decorated object.

As it is, I will solve the problem for now. Once other people or contributed modules start "decorating" the same service, it's going to be a nightmare, as the best solution for this would be to have this implemented in web-forms module as a global setting. How many other similar cases will happen that this hierarchy make problematic

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

This is intentional. However, it may change in the future.

Are there other reasons having it implemented that way initially?

Yes, because this is only proceed if you know what you are doing, this is unsupported behavior.

Once other people or contributed modules start "decorating" the same service, it's going to be a nightmare

They should not do it.

IMO in the end all boils down to the convinient-but-very-flawed data modelling through paragraphs. It makes you face an awkward decision after another. I don't think you are alone in that, but I don't want to pave this path and make it seem it's a recommended / supported one.

That being said I'm very interested in having some thoughts about your experience with Paragraphs + decoupled.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.