Content translation create access check with context for the target translation

The patch moves translation access logic to an own translation_access handler (ContentTranslationAccessControlHandler ) and makes it easy to allow modules to check per-entity if it is allowed to create/update/delete an entity translation. Maybe we should add an EntityValidation Handler to validate on save .
The $context for createAccess contains the translation language as langcode and the entity as source_entity.
I marked getTranslationAccess() as deprecated. Hope this points into the right direction.

Now with correct root folder

1. +++ b/core/modules/content_translation/content_translation.api.php
   @@ -0,0 +1,72 @@
   + * @see \Drupal\content_translation\ContentTranslationHandler
   + *
   + * @ingroup content_translation
   + */
   +function hook_entity_translation_access(\Drupal\Core\Entity\EntityInterface $entity, $operation, \Drupal\Core\Session\AccountInterface $account) {
   +  // No opinion.
   +  return AccessResult::neutral();
   +}
   +
   +/**
   

   Have you seen the discussion in the related issue?

   I don't see how there can be a difference between the existing access checks for update/delete *if* we ensure that the entity is passed in in the right language.

2. +++ b/core/modules/content_translation/content_translation.api.php
   @@ -0,0 +1,72 @@
   + *   An associative array of additional context values. By default it contains
   + *   language and the entity type ID:
   + *   - entity_type_id - the entity type ID.
   + *   - langcode - the translation language code.
   +
   + * @return \Drupal\Core\Access\AccessResultInterface
   + *   The access result. The final result is calculated by using
   + *   \Drupal\Core\Access\AccessResultInterface::orIf() on the result of every
   + *   hook_entity_translation_access_create() implementation, and the result of the
   + *   permissions checks in createAccess() method in the content access
   + *   translation handler.
   + *
   + * @see \Drupal\content_translation\ContentTranslationHandler
   + *
   + * @ingroup content_translation
   + */
   +function hook_entity_translation_access_create(\Drupal\Core\Entity\EntityInterface $entity, \Drupal\Core\Session\AccountInterface $account, $context = []) {
   +  // No opinion.
   

   The create access on the other hand is different, there we need additional information (the language, not sure what else, the entity type id is not needed, you can get that from the entity)

   My suggestion would be to limit this issue to create access only, like the issue title says, and leave it to the referenced issue to figure out how to dea with update/delete.

Sorry now i get it and you are completly right. It does not make sense to have own checks for update/delete

Maybe we don't need them for create either. Simple call the EntityAccessControlHandler::createAccess and simple provide the "source translation entity id" as $context parameter inside the overview controller. Lancode is already a context parameter.
(Would need another patch to handle the static cache correctly inside EntityAccessControlHandler)

Another option would be to move access logic to an own handler (ContentTranslationAccessControlHandler with createTranslationAccess and getTranslationAccess)

In both cases we must call the check also "before save" because only than we have the correct language.

What do you think?

#3018576: Content translation should allow for a language-aware access checks deprecates getTranslationAccess() which means this issue can't make it into core if so.
Please use #3056020: Content translation access control to agree on an implementation plan.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Have not reviewed but changes should be in MRs please