Problem/Motivation

This is a follow up to an issue reported to the Drupal Security Team, but it's been decided this can be dealt with in a public issue.

Core's Content Translation module allows for the "Authored by" field to be translatable for a given content type (see this blog post by Gábor Hojtsy which is a few years old but still seems to reflect the current state of this functionality).

However, whether "Authored by" is set to be translatable or not, and whether the "Hide non translatable fields on translation forms" option is selected or not, it seems that the "Authored by" field always appears in the node edit/translation form and it seems like users can change the value (including the autocomplete functionality which looks up users and adds their uid to the input). Changing this value in the edit/translate form doesn't actually seem to change the value which is displayed in the "Submitted by" field when viewing the translation of the node as far as I can see, which seems quite confusing.

The "Submitted by" field displayed when viewing a node does reflect the (original?) author of the translation if "Authored by" is set to be translatable for that content type, but even in that case changing the value in the edit/translation form doesn't seem to change the user shown as having "Submitted" the translation.

This is all quite confusing for the user(s).

Steps to reproduce

  • Enable Content Translation and dependencies on a blank D8 site.
  • Add a 2nd language (e.g. French), leave English as the default.
  • Edit content language settings (/admin/config/regional/content-language) for a content type (e.g. Article) and make "Authored by" translatable.
  • Add three test users (foo, bar, baz) with no special roles.
    • for u in foo bar baz; do drush ucrt $u ; done
  • Grant authenticated users permissions to Article: Create new content, Create translations, Edit translations, Translate Article content.
  • As foo create a new article with some basic content in English.
  • As bar translate the article into French.
  • As baz observe the "Submitted by" value on the article and its translation (bar submitted it).
  • As bar edit the translation of the article, and try to change the "Authored by" value to one of the other users (e.g. foo).
  • As baz observe the "Submitted by" value on the article and its translation (should be foo).
  • Edit the content language settings again and disable the translatable option for "Authored by" on the content type.
  • Repeat the create / translate / edit steps above as the different users.
  • Edit the content language settings again and enable the "Hide non translatable fields on translation forms" option.
  • Observe that all of the users can still see and edit the "Authored by" field when editing translations.

Other variations on these steps include changing the "Authored by" on a translation when that field is set as translatable, but as a user other than the original author and translator. This doesn't seem to do anything. I think we've enumerated enough steps and combinations to make the point now though.

Proposed resolution

If the value cannot be changed, the field shouldn't appear in the form. If it should be possible to change the value, doing so in the edit form should be reflected in the values displayed when viewing the translation.

Remaining tasks

  • Identify whether one or more bugs are causing the apparently confusing UI.
  • Fix those bugs.

User interface changes

TBC

API changes

TBC

Data model changes

TBC

Release notes snippet

TBC

Issue fork drupal-3032675

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

mcdruid created an issue. See original summary.

mcdruid’s picture

Issue summary: View changes
mcdruid’s picture

Issue summary: View changes
mcdruid’s picture

Issue summary: View changes
mcdruid’s picture

Issue summary: View changes
mcdruid’s picture

Issue summary: View changes
anavarre’s picture

Issue summary: View changes
Issue tags: +DrupalWTF

Thanks for the detailed step-by-step. I could reproduce 100%. Seems we have both a logic and an Access Bypass-ish issue.

mcdruid’s picture

Issue summary: View changes

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

berdir’s picture

Didn't read in detail, but sounds like a related/duplicate of #2971390: Make exposure of translation meta fields conditional which stops showing extra fields if there are corresponding base fields.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

lisa.rae’s picture

So, I just tried to duplicate this issue with a fresh D11 site install, walking through the steps that the OP outlined. I am not able to edit the "Authored by" field through the UI, even though it is set to translatable in the configuration. This appears to be the case whether or not the "Hide non translatable fields on translation forms".

The test users in this test case are testuser1 (language English), testuser2 (language Spanish), and testuser3 (language English)

Basic page is configured for translations, and content type is configured to display the author by and authored on date on the Basic page entity. Revisions are being tracked.

English content (original) created by testuser1.
Spanish content translated by testuser2.
English content is revised by admin user (user 1).

testuser1 always shows as the author for the English version, and testuser2 always shows as the author for the translated version. Once the initial nodes are created, even with revisions to the English content by the "admin" user (user 1) the authored by field remains unchanged.

If you expand the "Translations" tab in the sidebar (I'm using the Olivero theme for the test install), edit the content and change the author, the original author remains displayed as the node author, even if the translation is marked as outdated.

So the open question:

* Should the "Authored by" field be changeable or not, when a node is edited?
* If the answer is no, then why show the "Authored by" field as translatable on the content translation configuration form for the node type (in this case, basic page)?

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

w01f’s picture

Just throwing this out there as well - it would be nice if there were a UI config option to swap the "authored by" and "author name" text.

In Japanese, for example, it's very common to have

アマンダ 執筆 or アマンダによる (Amanda written by) where the name comes before the "writing/authored by" text.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.