When source has the status EDITED and then a target translation is downloaded the target status is set to CURRENT (see https://www.drupal.org/node/2780933 , it should be NOT_CURRENT) this behavior is not specifically mentioned in the Lingotek Connector Requirements document but rather in the ticket https://www.drupal.org/node/2780933 and the Source status is set to CURRENT even though an outdated target translation is downloaded and has nothing to do with the source, the expected behavior would be for the source status to stay the same. According to the Lingotek Connector Requirements the only action to set the Source state to CURRENT is the successful upload of the source to the TMS.
Comments
Comment #2
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #4
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #5
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #6
penyaskitoI would love a test showing this bug, so we can ensure we are fixing it.
Comment #7
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #9
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #11
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #12
t.murphy CreditAttribution: t.murphy at Lingotek commentedThere is now a working test for this that ensures the problem is being fixed.
Comment #13
penyaskitoI don't think we need these comments. We can add one in the if clause explaining the code, but IMHO we shouldn't explain code that we are removing.
These ones could be simplified to
Do we need the same logic in downloadConfig()?
We would need the same test for a config entity and a config object for ensuring that we have proper coverage. We are only covering content here, and we already had issues maintaining those in sync (at some point we should unify this logic and remove code duplication for content entities, config entities and config objects)
Comment #14
penyaskitoAlso, let's assert positively. Instead of asserting that the status is not current, let's assert for the status we actually expect it to be.
Comment #15
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #17
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #19
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #21
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #23
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #24
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #26
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #28
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #30
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #31
penyaskitosrc/Tests/LingotekNodeStatusDownloadTargetTest.php
already exists, so this patch doesn't apply anymore, could you reroll it?Comment #32
penyaskitoI had this locally, I need to try again.
Comment #33
penyaskitoSplitting the patch for having one with only the tests, so ensures that we are adding coverage to this issue. Patch is exactly the same.
Comment #36
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #39
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #42
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #45
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #47
t.murphy CreditAttribution: t.murphy at Lingotek commentedComment #49
t.murphy CreditAttribution: t.murphy at Lingotek commentedTests have been updated and it is expected for the only-tests patch would fail because in order to pass it needs the code changes from the patch.
Comment #50
penyaskitoThis looks good to me.
Comment #52
penyaskitoCommitted 3d9564f and pushed to 8.x-2.x. Thanks!