MediaLibraryFieldWidgetOpener::checkAccess denies access when modifying field values on a translated entity revision

Same problem here!
I will try the patch

Added patch from the MR.

mglaman → closed merge request !303

@smustgrave is there anything else that should be reviewed? In our case, the patch seems to work well.

Left some comments on the MR and this will still need a test

This seems that is not working on the create operation because the method getTranslationFromContext checks the translations that already exist.

  public function getTranslationFromContext(EntityInterface $entity, $langcode = NULL, $context = []) {
    $translation = $entity;

    if ($entity instanceof TranslatableDataInterface && count($entity->getTranslationLanguages()) > 1) {

I'm running into an edge case that's even trickier, in combination with 🐛 Layout builder fails to assign inline block access dependencies for the overrides section storage on entities with pending revisions Needs work as well as contrib layout builder modules, somehow the revision doesn't match what layout builder has.

But I suspect it's neither this nor the other issue, because what matters for layout builder is the revision id, which is the same. And i'm also seeing access denied results within the layout builder edit form for the delete button access check, so it's also confused about that. The site also uses modules like layout_builder_st and the content was cloned, so there so many possible things that could have and did go wrong.

Just documenting my findings for now in case someone else runs into a similar issue. Considering a custom patch that just grants full unconditional access to anything as we have no access restrictions for editors.

I have a translator role that doesn't have edit permissions. I also encountered the same when adding/updating translations with this role that AJAX error happens with message that user needs edit permission for entity type where media field is calling media library in order to change field value. I made a patch for this but not sure if it's the right approach or if it covers all situations but what I tested and works is that user with just `translate any entity` and without `edit` permissions is able to either create new translation and also update media field. Editing existing translation and updating media field also works. Solution also covers translating entities other than nodes e.g. taxonomies with media field etc.

I've just hit the same issue. I'm busy enabling translation on my site, having had issues years back with Media when it was a contrib module, I'd resisted implementing. Enabled it in D10 and hit this. Media does give a nice interface, but this issue means it is still unusable.

I tried @miksha's patch ( https://www.drupal.org/project/drupal/issues/3197416#comment-15325059 🐛 MediaLibraryFieldWidgetOpener::checkAccess denies access when modifying field values on a translated entity revision Needs work ) and it would not apply.

I've applied both patchs and the issue is fixed for me.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

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

Just re-ran composer update and second patch (#20) won't apply, but I'm working fine with the first patch (#13)

I tested 11.x locally and it still has the same issue that my patch in #20 fixes. I created a new MR against 11.x and combined changes from both #13 & #20 patches. For me this fixes the AJAX error when translator role user has permissions like defined in issue description under Steps to reproduce but at the same time has no edit permissions.

Was previously tagged for tests so moving to NW for those.