Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Refactor everything to be service based so it can be overridden.
Decomplicate permission checks.
Fix cache issues.
Check permissions on menu items (but not menu edit form, just yet).
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | save button missing.png | 61.55 KB | heddn |
| #5 | add translation.png | 54.02 KB | heddn |
| #2 | allowed_languages-service_refactor-3179076-2.patch | 32.67 KB | nterbogt |
Comments
Comment #2
nterbogt commentedComment #4
nterbogt commentedThe 2.x-dev release needs review by other module users.
Comment #5
heddnNot sure it matters, but I'm running 9.1.0-rc1.
I think I found an issue. Let me see if I can coherantly describe how to reproduce. Grant a user a role that gives them ability to translate a language. But don't give them permission to the source language. Only the destination. (destination = Castilian Spanish, source = world-wide English).
If a translation does not exist yet and I don't have access to both the source and destination languages, then the save button on the page doesn't surface.
ContentTranslationController:add()calls$form_state_additions['content_translation']['translation_form'] = !$entity->access('update');. This in turn eventually callsallowed_languages_entity_access. But the entity passed in has world-wide english, not castilian spanish. So access is denied and the save button on the node is hidden later byContentTranslationHandler::entityFormSharedElements().Comment #6
heddnLinking the solution, which seems to be a core bug #3184787: Source translation used instead of target when determining translation permissions.
Comment #7
heddnThis has a commit. And looks fixed.