Een hart voor de Drupal Community

Tested this MR.

I removed all content_translation permissions from a given user. They could no longer see the "Translations" tab in that case.

However, when given the "Create AI translation" permission, they could still access the translation URL directly, and a translation was added. Not sure if this is desired behaviour, or if it should be an AND operation: only create AI content translations when you have "create ai content translation" permission + the appropriate content_translation permission as well.

So the original issue raised in this topic was not yet fixed, AFAIK.

The improved logic to hide the AI Translation column when not relevant, seems to work and is definitely an improvement.

I also took the opportunity to add extra config validation to the schema. This is useful for when ai_translate settings get set via another means than the settings form, e.g. via a recipe.

This also lays the groundwork for simplifying the settings form, by using #config_target for all / relevant form elements.

• Fixed the entity_reference_depth that was wrongly positioned in the default config
• Added missing language_settings default value
• Updated default reference_defaults values. Now it defaults to empty, since it was referencing entity types that might not even exist on a given site, making the configuration valid more of a challenge.

The last change might be debatable...

svendecabooter created an issue. See original summary.

Problem/Motivation

The config schema for ai_translate module is defined in modules/ai_translate/config/schema/ai_translate.schema.yml.

The default config upon installation of the module is defined in modules/ai_translate/config/install/ai_translate.settings.yml, but does not follow the exact schema.

Noteably, the option `entity_reference_depth` is added within the reference_defaults array, instead of on its own.

Deprecation warnings have been fixed in the new OpenAiBasedProviderClientBase class. Pipeline still gives a PHPUnit error in Drupal\Tests\ai\Kernel\Utility\TextChunkerTest Not sure how this is related to this issue...

Sven Decabooter added a comment on drupal.org: Pass AI token usage data to the events

Use OOP hooks, as per https://www.drupal.org/node/3442349

svendecabooter created an issue.

Added a fix that should address this issue.

Thanks, that seems like a good addition.

Could we also take the opportunity to set autowire: true in the services defined in externalauth.services.yml? Autowiring is supported since 9.3, and since our min. required version is 9.5, that should work.

Sven Decabooter added a comment on drupal.org: Exception: Serialization of 'Closure' is not allowed in serialize()

Sven Decabooter added a comment on drupal.org: Exception: Serialization of 'Closure' is not allowed in serialize()

svendecabooter made their first commit to this issue’s fork.

Sven Decabooter added a comment on drupal.org: Support Symfony Mailer

It is made backwards compatible from Drupal 10.1 on, with the #[LegacyHook] attribute. See https://www.drupal.org/node/3442349#hook_convert That's already added in this MR - so could still go into 3.2.x if desired.

Sven Decabooter added a comment on drupal.org: First draft of module

Sven Decabooter added a comment on drupal.org: [roleassign] RoleAssign

Sven Decabooter added a comment on drupal.org: Modal Does not Close Automatically (possibly only on multilingual sites)

Sven Decabooter added a comment on drupal.org: Automated Drupal 11 compatibility fixes for route_condition

Sven Decabooter added a comment on drupal.org: Automated Drupal 11 compatibility fixes for teamleader

Sven Decabooter added a comment on drupal.org: Support OOP hooks

Sven Decabooter added a comment on drupal.org: Deprecate module for ai 1.2.x

No longer needed - see #3536212: Deprecate module for ai 1.2.x

No longer needed - see #3536212: Deprecate module for ai 1.2.x

Rebasing / fixing of merge conflict causes a new issue in test Drupal\Tests\openid_connect\Functional\Update\IssAllowedSchemaUpdate30004Test::testUpdateHook30003

Not sure how this is related, except that earlier hook also updated plugin config. Maybe it now fails because in our update hook we also update the plugin config further. Any insights from maintainers as to how to solve this would be appreciated.

Updated the MR to fix a merge conflict with hook_update_x numbering.

Sven Decabooter added a comment on drupal.org: Implement OOP preprocess hook

svendecabooter created an issue. See original summary.

Problem/Motivation

Add support for Preprocess OOP hooks. See https://www.drupal.org/node/3496491 Add backwards compatibility.