Steps to reproduce:
- Enable Language and Content translation module
- Add a language to the site
- Set Poll to be translatable at admin/config/regional/content-language
- Navigate to admin/content/poll
- Create a new poll
- Translate the poll to another language
- 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.
| Comment | File | Size | Author |
|---|
Issue fork poll-2913992
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
Comment #2
vegantriathleteFYI: 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.
Comment #3
vegantriathleteI've started debugging and here is what I've noticed. On
/es/poll/2/translationsthe 'delete' link hashref="/es/poll/2/delete"whereas for/es/user/23/translationsthe 'delete' link hashref="/es/user/23/translations/delete/es". There is the issue. Now I've got to figure out how the link is being created.Comment #4
vegantriathleteIf I manually navigate to
/es/poll/2/translations/delete/esI 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.Comment #5
vegantriathleteThe route name for path
/poll/{poll}/translationsisentity.poll.content_translation_overviewand the route name for/user/{user}/translationsisentity.user.content_translation_overview.Comment #6
vegantriathleteWhen I `grep -r content_translation_overview ./core/modules/content_translation` the results I get are:
Comment #7
vegantriathleteI get the same results when I grep from the installation root.
Comment #8
vegantriathleteWhen I check the route column it is the same for user and poll, with the expected difference being that poll is substituted for user.
Comment #9
vegantriathleteIt 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.
Comment #10
vegantriathleteHere'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?
Comment #11
vegantriathleteComment #12
berdirI think we lost this information here, which seems useful to keep.
Tests would be great too.
Comment #13
sja112 commentedComment #14
berdirNot 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.
Comment #15
bramdriesenNeed to check if this is still the case on 2.0.x
Comment #16
bramdriesenCan confirm this is still the case. Quite a critical bug in my eyes.
Comment #18
bramdriesenComment #19
bramdriesenComment #20
bramdriesenTest only testrun fails as expected.
Comment #21
bramdriesenRe #10
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).
Comment #22
ivnishI tested it manually using steps for reproduce. MR fixing the issue
Comment #23
bramdriesenThanks!