When you duplicate a variation the creation time from the original is copied to the new variation. This interferes with the usefulness of the creation time field on variations. It should be set to the time the duplicate variation was created.
While this isn't displayed anywhere on variations it is useful for business logic that uses things such as the Drupal API to set prices, update listings, etc which this potentially interferes with.
Edit the form display for the default variation type. Ensure created field is enabled so you can see the creation time.
Create a product with a variation. Go to the variations tab on the product and duplicate a variation. Check the creation time of the duplicate.
Show commandsStart 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:
changes
Comments
Comment #2
rhovlandComment #4
rhovlandReady for review. Adds a createDuplicate() function to the entity which is executed by the EntityDuplicateEvent in the entity module when a duplicate entity form is loaded. This sets the created time to now after copying the contents of the existing entity.
Wrote a test. The test passes but there are unrelated failures in phpunit (previous major) which is why it's marked as failed.
Comment #5
jsacksick commentedhm... Shouldn't we nullify the created time instead on createDuplicate()? So it's set on save properly automatically? If the form is submitted much later, then the created time wouldn't be accurate?
I'm guessing we need to do the same for products as well?
Comment #6
jsacksick commentedComment #7
rhovlandThat's a good point. Product duplication is not yet implemented in core so to do the same would mean modifying the MR in that issue. I mostly just copied code from the duplicate product issue.
I'll try unsetting the creation time instead and see what that does.
Comment #9
tbkot commented@jsacksick I've tried just to reset the creation/update timestamps, and still, when the "save" is called, the values are empty. We have to set proper timestamps in the "createDuplicate" method to be safe. In general, those values are already preset when the entity object is created by storage, which is not called when the entity is duplicated.
Comment #10
jsacksick commentedOk thanks for reporting back, makes sense, I mixed up the ChangedItem logic which sets the changed time on presave(). CreatedItem doesn't have such logic and I can understand why.
Comment #11
jsacksick commentedhm... Why do we need to set the changedTime()? This should be overridden on presave() no? What happened with the merge commit? The diff seems messed up.
Comment #12
jsacksick commentedThe tests are failing. Setting this to Needs work.
Comment #13
rhovlandTest probably fails because the test was changed to test the changed time too and used
$variation->setchangedTime($time)instead of$variation->setChangedTime($time).Comment #14
tbkot commentedjsacksick tests pass now. I have to set the "changed" timestamp in the "createDuplicate"; otherwise, it will use the value from the original variation. We cannot rely on
ChangedItem::preSaveas it has conditions which prevent value update. When the "changed" value is NULL, theChangedItem::preSaveis not called at allComment #15
tbkot commentedComment #17
jsacksick commentedMerged, thanks!!