Contrib.social

Introduce more flexible access control for content translation operations

Open on Drupal.org →
Created on 13 December 2013, over 10 years ago
Updated 9 March 2023, over 1 year ago

Problem/Motivation

Currently the Content Translation module performs its access checks through a confusing combination of swappable/overridable OO code, procedural callbacks and entity-info-driven callbacks. This makes it hard for entity-defining modules to customize access checks to fit their business logic in clean way.

Proposed resolution

Unify and streamline access checks by relying on a proper entity access controller implementation for translation operations.

Remaining tasks

  • Answer #33
  • Agree on an implementation plan
  • Write a patch
  • Reviews

User interface changes

None

API changes

Three new entity access operations used by content_translation:

  1. translation_create
  2. translation_update
  3. translation_delete
📌 Task
Status

Needs work

Version

10.1 ✨

Component
Content translation  →

Last updated 2 days ago

No maintainer
Created by

🇮🇹Italy plach Venezia

Live updates comments and jobs are added and updated live.
  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

  • Security

    It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇺🇸United States smustgrave

    This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

    Believe #33 still needs answer.

    This almost seems like it could be fixing a bug? Even though it's a task I do think it should have test coverage.

  • Comment over 1 year ago →
    🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium

    Re #33:

    Not sure right now if making $translation->access('delete') specific to only deleting a translation and not the entity is an API/behavior change or if it is already kind of working like that, maybe not on the translation overview page but on the delete route. It's just /language/node/X/delete, so that means it's the regular _entity_access route requirement?

    It absolutely is, just look at revisions. All of the delete/update/whatever revision operations are being check against the main entity. I don't see why we wouldn't check translation operations against the original entity either.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024