Steps to reproduce:

  1. Enable Language and Content translation module
  2. Add a language to the site
  3. Set Poll to be translatable at admin/config/regional/content-language
  4. Navigate to admin/content/poll
  5. Create a new poll
  6. Translate the poll to another language
  7. Delete the translation

The expected result is that the translation will be deleted but the original source language will remain. The actual outcome is that both versions are now gone.

Disclaimer: I am filing this issue because I am experiencing the exact same problem with a custom entity I have defined and I have been completely unable to figure out what I'm missing in my entity definition. I was hoping that this module was going to have it working, as it's the closest example to what I'm doing that I've found so far. [I've looked at Node, User, Taxonomy, Block Content, and Media Entity and can't figure out what they are doing differently. All of them allow bundles, though. So, they are not the greatest match for my use case.]

I am happy to discuss this with you and to help write a patch to fix this module so that I can learn what I need to do to fix mine as well.

Issue fork poll-2913992

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

vegantriathlete created an issue. See original summary.

vegantriathlete’s picture

FYI: I tested configuring users (which are also entities that don't have bundles) as translatable and don't run into this same issue. So, I don't think this is a core bug in handling translations for bundle-less entities. However, I haven't actually tracked down where the issue *is*. I'm going to see if I can figure out why this does work as expected with the User entity and maybe that will give the answer I'm looking for.

vegantriathlete’s picture

I've started debugging and here is what I've noticed. On /es/poll/2/translations the 'delete' link has href="/es/poll/2/delete" whereas for /es/user/23/translations the 'delete' link has href="/es/user/23/translations/delete/es". There is the issue. Now I've got to figure out how the link is being created.

vegantriathlete’s picture

If I manually navigate to /es/poll/2/translations/delete/es I get an Access denied error. FWIW: I'm signed in as User 1, so it's especially strange that I'd get and Access Denied. And, of course, I'm not getting an Access denied at /es/user/23/translations/delete/es.

vegantriathlete’s picture

The route name for path /poll/{poll}/translations is entity.poll.content_translation_overview and the route name for /user/{user}/translations is entity.user.content_translation_overview.

vegantriathlete’s picture

When I `grep -r content_translation_overview ./core/modules/content_translation` the results I get are:

core/modules/content_translation/content_translation.services.yml:      - { name: access_check, applies_to: _access_content_translation_overview }
core/modules/content_translation/tests/src/Unit/Menu/ContentTranslationLocalTasksTest.php:        ['drupal:content-translation-overview', 'entity.node.content_translation_overview'],
core/modules/content_translation/tests/src/Unit/Menu/ContentTranslationLocalTasksTest.php:        'content_translation.local_tasks:entity.node.content_translation_overview',
core/modules/content_translation/tests/src/Unit/Menu/ContentTranslationLocalTasksTest.php:      ['entity.node.content_translation_overview', [[
core/modules/content_translation/tests/src/Unit/Menu/ContentTranslationLocalTasksTest.php:        'content_translation.local_tasks:entity.node.content_translation_overview',
core/modules/content_translation/src/Controller/ContentTranslationController.php:    $build['content_translation_overview'] = [
core/modules/content_translation/src/Routing/ContentTranslationRouteSubscriber.php:          '_access_content_translation_overview' => $entity_type_id,
core/modules/content_translation/src/Routing/ContentTranslationRouteSubscriber.php:      $route_name = "entity.$entity_type_id.content_translation_overview";
core/modules/content_translation/src/Plugin/Derivative/ContentTranslationContextualLinks.php:      $this->derivatives[$entity_type_id]['route_name'] = "entity.$entity_type_id.content_translation_overview";
core/modules/content_translation/src/Plugin/Derivative/ContentTranslationLocalTasks.php:      $translation_route_name = "entity.$entity_type_id.content_translation_overview";
vegantriathlete’s picture

I get the same results when I grep from the installation root.

vegantriathlete’s picture

When I check the route column it is the same for user and poll, with the expected difference being that poll is substituted for user.

vegantriathlete’s picture

It looks like content_translation has provided all the same link templates for user and poll.

Things seem to take a change when I'm looking in ContentTranslationManageAccessCheck. Specifically, it looks like the User entity does not provide a template for a delete form and poll does provide a template for a delete form. Because the access check sees that there is a form it returns AccessResult::forbidden() as it assumes that the deletion with be handled by the entity itself. I am assuming that it's this forbidden access that causes the href to point to the entity delete form as well.

vegantriathlete’s picture

Here's a patch that moves us in the right direction. I'm not sure why the redirect URL doesn't seem to be getting picked up.

Also, we'll want to write tests for this bug.

Finally, we'll probably also want to do something similar for Poll Choice. Perhaps that should be a separate issue?

vegantriathlete’s picture

Status: Active » Needs review
berdir’s picture

Status: Needs review » Needs work
+++ b/src/Form/PollDeleteForm.php
@@ -2,27 +2,40 @@
    * {@inheritdoc}
    */
-  public function getDescription() {
-    return t('All associated votes will be deleted too. This action cannot be undone.');

I think we lost this information here, which seems useful to keep.

Tests would be great too.

sja112’s picture

Status: Needs work » Needs review
StatusFileSize
new2.29 KB
berdir’s picture

Status: Needs review » Needs work
+++ b/src/Form/PollDeleteForm.php
@@ -2,27 +2,40 @@
    * {@inheritdoc}
    */
-  public function getDescription() {
-    return t('All associated votes will be deleted too. This action cannot be undone.');
+  protected function getDeletionMessage() {
+    /** @var \Drupal\poll\PollInterface $entity */
+    $entity = $this->getEntity();

Not sure what the latest patch changed exactly, but the description is still gone and I think that is still useful to have.

On the other hand, logDeletionMessage() and getDeletionMessage() do not actually seem to be that useful and the default implementation is good enough IMHO, so fine to just drop that.

bramdriesen’s picture

Version: 8.x-1.x-dev » 2.0.x-dev
Issue tags: +Needs tests, +Needs manual testing, +Needs issue fork

Need to check if this is still the case on 2.0.x

bramdriesen’s picture

Title: Deleting a translation deletes the entire entity id » Deleting a translation deletes the entire entity
Issue summary: View changes
Priority: Normal » Critical
Issue tags: -Needs manual testing

Can confirm this is still the case. Quite a critical bug in my eyes.

bramdriesen’s picture

Issue tags: -Needs issue fork
bramdriesen’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
bramdriesen’s picture

Test only testrun fails as expected.

bramdriesen’s picture

Re #10

Finally, we'll probably also want to do something similar for Poll Choice. Perhaps that should be a separate issue?

I don't think this is needed. I tested a bit and I highly doubt anyone would want to remove the translation of a choice in that way. Currently the choices are kept in sync between the source and the translations, which I think is what we want! You don't want to end up with 3 choices in one language and 4 in another.

One thing I noticed, which needs a follow up issue is that the prompts to delete a vote or choice are not being shown. Your vote and option are just being deleted without the warning being shown (tested on 2.0.x without the change in this issue).

ivnish’s picture

Status: Needs review » Reviewed & tested by the community

I tested it manually using steps for reproduce. MR fixing the issue

bramdriesen’s picture

Status: Reviewed & tested by the community » Fixed

Thanks!

  • bramdriesen committed 719c86b9 on 2.0.x
    Issue #2913992 by bramdriesen, vegantriathlete, sja112, berdir, ivnish:...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.