Add revision support to products and product variations

https://github.com/drupalcommerce/commerce/pull/451

Tests fail.

So, 8.3.0 has hit, #2721313 is RTBC but not committed yet, does that mean we are still just waiting until a core release which includes that patch?

I'm curious what the state of the PR is, also--as of last year there was a comment on it that it was ready for review, but I'm assuming much has changed in Commerce since then that may have affected some of that work from so long ago.

Would be great to have revisions for orders as well (disabled by default)

HI @bojanz

Thanks for your reply

If on the project customer require to show not only logs, but side by side order diff we need custom module and order entity type alter there to make this fucntionality.

Not sure that custom module is good sullution for this case

@niko- Better to have this as contrib module

I have taken an initial stab at adding revisioning support to products using the new functionality available in Drupal 8.4+.

Patch updated to support Commerce 2.9.

Added better permission handling.

Just updated patch (#19) according to current dev.

The same with the right hook_update and post_update numbers.

And another one for compatibility with PHP 7.2

Hello!

The small fix to resolve conflicts with the new dev branch.
P.S. it works for me.

There is a lot of mentions for "Asset".
But the critical one is checking for "revert all asset revisions" and "delete all asset revisions" permissions, that missed.

So that mean, only superadmin (uid = 1), has access to operate with revisions.

re-roll the hook_updates to the new version of commerce, and fix the permissions issue (see interdiff).

There were a couple of bugs with routes of the translation revert and the way the revert form was setup and extended the entity API revert form.

Fixed this by comparing the implementation of the core node translation revert form with this and updated the patch.

Doing this I somewhat think that the Entity API version of the revert form should be updated to be more inline with the setup of the core Node version.

Small bug in de route name. Fixed it.

We are trying this patch out and are running into the following message in the Status Report

"Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Product
The Title field needs to be updated."

Not sure it's related to this patch, but it's what i've change recently. I've run drush updb, but still have the message. Do i need to do something different to update this field?

Yeah, that is a pain... I had a similar issue. Look into this:
https://www.drupal.org/project/devel_entity_updates

I tried using that module and running drush entup, but I'm getting these messages and it's not able to complete the update.

array_intersect_key(): Expected parameter 1 to be an array, null given
SqlContentEntityStorageSchema.php:2494

[warning]
Drupal\Core\Entity\Exception\FieldStorageDefinitionUpdateForbiddenException: The SQL storage cannot change the schema for an existing field (title in commerce_product entity) with data. in
[error]

This may not be the right spot to post this, so if someone could point me in the right direction, I would be grateful.

I think I made a huge mistake. I was trying out this patch and it seemed to be working well for what i needed. I didn't notice the issue mentioned in #30 at the time, and pushed it into my Production code/env. Big oops, right?

Now, I find I can't rollback the patch without getting lots of errors (can provide if needed). I'm nervous that I will have trouble with future Commerce updates (this patch hasn't applied for me against latest Commerce dev).

Is there any direction/tutorials that can help me figure out how to "undo" this? Am I seriously in trouble?

Thank you.

reroll against 2.19

Issue with duplicate

With the latest patch I am getting this error:

Error: Class 'Drupal\commerce_product\Entity\LanguageInterface' not found in Drupal\commerce_product\Entity\Product->ensureTranslations() (line 380 of /app/web/modules/contrib/commerce/modules/product/src/Entity/Product.php)

I resolved it by adding the following use statement and the error went away. Is this correct?

use Drupal\Core\Language\LanguageInterface;

Fixed patch to address issue in #38. Patch is against latest 2.x.

Wit the recent progress, i think this should now be built with the referred core patch.

I added this patch to make compatible with Drupal 9.1 and Drupal Commerce 2.24

+++ b/modules/product/commerce_product.post_update.php
@@ -130,3 +131,25 @@ function commerce_product_post_update_7() {
+function commerce_product_post_update_8(&$sandbox) {

Why do we have a post update function completely commented out?

+++ b/modules/product/commerce_product.install
@@ -20,6 +20,22 @@ function commerce_product_install() {
+  if (\Drupal::moduleHandler()->moduleExists('content_translation')) {
+    $dependencies['commerce_product'][8400] = [

This doesn't look correct to me...

$dependencies['commerce_product'][8400]

There's no commerce_product_update_8400

I haven't reviewed the rest yet, but these 2 things are weird to me.

Hello, I am using Drupal 9.1.9 and Drupal commerce 2.24. I have tried this patch "commerce-add_product_revision-2656896-42.patch" and it is not working. After implementing this patch, there is no option coming to view product revisions in the Drupal admin.

Hallo, I'm using Drupal 9.2.6 and commerce 2.27.
Using the patch #42. Can not run through the pending entity updates.

Product
The Author field needs to be updated.
Stock location
The User ID field needs to be installed.

Any ideas?
I always get the following errors:

 Exception thrown while performing a schema update. SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the ma  
  nual that corresponds to your MariaDB server version for the right syntax to use near 'NOT NULL' at line 1: ALTER TABLE "commerce_product_field_revision" CHA  
  NGE `uid` `uid`  NOT NULL; Array                                                                                                                               
  (                                                                                                                                                              
  )

Thanks for your help.

@sistocarta you need to install the field

    $entityDefinitionUpdateManager = \Drupal::entityDefinitionUpdateManager();
    $field = BaseFieldDefinition::create('entity_reference')
      ->setLabel(t('Revision user'))
      ->setDescription(t('The user ID of the author of the current revision.'))
      ->setSetting('target_type', 'user')
      ->setRevisionable(TRUE)
      ->setDefaultValueCallback('uid');
    $entityDefinitionUpdateManager->installFieldStorageDefinition('uid', 'commerce_product', 'commerce_product', $field);

We migrate our Commerce to the latest version and to Drupal 9.2.7. After this, we was not able to save a new product. Error on Log was: Drupal\Core\Entity\EntityStorageException: Field is unknown. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (Line 810 in XXX/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

The message "Field is unknown" was not meaningful, so we investigate it and found out, that the field revision_default was missing and Drupal Core search for this Field if you use revisions on an entity.

So the patch ”commerce-add_product_revision-2656896-42.patch“ will not work with the Drupal 9.2.7. Drupal Core calls the function getRevisionMetadataKey($key) which you find in ContentEntityType.php. The default value is there "revision_default" which Drupal puts, so if this is missing you became the "Field is unknown" issue.

You must add the field with the code bellow or adjust the patch with them.

$definition_update_manager = \Drupal::entityDefinitionUpdateManager();

    // Add the published entity key and revisionable metadata fields to the
    // commerce_product entity type.
    $entity_type = $definition_update_manager->getEntityType('commerce_product');
    $entity_type_id = $entity_type->id();

    $revision_metadata_keys = [
        'revision_default' => 'revision_default',
        'revision_user' => 'revision_user',
        'revision_created' => 'revision_created',
        'revision_log_message' => 'revision_log_message',
      ];

    $entity_type->set('revision_metadata_keys', $revision_metadata_keys);
    $definition_update_manager->updateEntityType($entity_type);

    // Add the revision metadata fields.
    $baseFieldDefinitions['revision_default'] = BaseFieldDefinition::create('boolean')
      ->setName('revision_default')
      ->setLabel(t('Default revision'))
      ->setRevisionable(TRUE);

    $baseFieldDefinitions['revision_created'] = BaseFieldDefinition::create('created')
        ->setLabel(t('Revision create time'))
      ->setDescription(t('The time that the current revision was created.'))
      ->setRevisionable(TRUE)
      ->setInitialValueFromField('created');

    $baseFieldDefinitions['revision_user'] = BaseFieldDefinition::create('entity_reference')
    ->setLabel(t('Revision user'))
      ->setDescription(t('The user ID of the author of the current revision.'))
      ->setSetting('target_type', 'user')
      ->setRevisionable(TRUE)
      ->setInitialValueFromField('uid');

    $baseFieldDefinitions['revision_log_message'] = BaseFieldDefinition::create('string_long')
    ->setLabel(t('Revision log message'))
      ->setDescription(t('Briefly describe the changes you have made.'))
      ->setRevisionable(TRUE)
      ->setDefaultValue('')
      ->setDisplayOptions('form', [
          'type' => 'string_textarea',
          'weight' => 25,
          'settings' => [
              'rows' => 4,
            ],
        ]);

    foreach ($revision_metadata_keys as $field) {
        $fieldStorageDefinition = $definition_update_manager->getFieldStorageDefinition('revision_created', $entity_type_id);
        if (isset($fieldStorageDefinition)) {
            continue;
    }
    $definition_update_manager->installFieldStorageDefinition($field, $entity_type_id, $entity_type_id, $baseFieldDefinitions[$field]);
    }

@cola #47 works for me to resolve the revision_default field.

Still, I am having

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Product

• The Author field needs to be updated.
• The Title field needs to be updated.
• The Created field needs to be updated.

Could you please help me to resolve this error?

Updated the patch from #42 and fixed issues with error messages about not existing fields during updating process, also fixed UI etc.
Tested on existing Drupal 9.1.13 site with some product types and products.

This won't go into 2.x.

Added revisions to product variations, but still need to fix update functions for existing site.

Improved update functions to add revisions tables to existing product variations. This patch is for 2.x

@khiminrm / @jsacksick - I'm a little concerned that we're changing the base class for Product from CommerceContentEntityBase to EditorialContentEntityBase. It looks like we'll be losing functions from our custom base class that I assume might be in use elsewhere:

• CommerceContentEntityBase::getTranslatedReferencedEntity()
• CommerceContentEntityBase::getTranslatedReferencedEntities()

Should we instead be making a CommerceEditorialContentEntityBase that extends core's and preserves these functions for our own uses?

Oh, additionally, I think a CommerceEditorialContentEntityBase should include a helper function for loading a referenced variation in the appropriate revision relative to the timestamp of the product revision.

Don't know exactly what that should look like, but if I've loaded an older revision of a Product, I'd look for something like $product->loadReferencedEntityRevisionByTimestamp() to load the version of a product variation that, by created time, would have been current at the given timestamp. (Understanding this may not be perfectly accurate, since the current revision may not have been the latest one ... but it would be close enough and could then theoretically be used to improve the revision view page to inject fields from the appropriate revision.)

I haven't really tested the patch manually, but one of first things I've noticed is the product controller, can't we use the \Drupal\entity\Controller\RevisionOverviewController? Or at the very least the trait offered by Entity API?

I agree with Ryan, I don't think it's worth extending another class. The only thing we're currently missing is the RevisionLogEntityTrait that the product is currently not using, all we have to do is use it and add:
$fields += static::revisionLogBaseFieldDefinitions.

Introducing CommerceEditorialContentEntityBase is a nice to have, but I don't think we're gaining a lot by introducing it.

@rszrama: Regarding $product->loadReferencedEntityRevisionByTimestamp(), I'm not sure why we'd need that? We usually load a revision by its ID?

Regarding the default_variation "field", it's computed and therefore shouldn't be marked as revisionable.

Also, if we really want to revision variations, then I think the product should reference a variation revision? Just afraid that'd potentially introduce bugs... A little bit hesitant to go all in with revisions as revisions are costly in terms of DB storage especially for sites with lots of products.

1. +++ b/modules/product/src/Controller/ProductController.php
   @@ -0,0 +1,226 @@
   +    $revision_ids = $commerce_product_storage->revisionIds($commerce_product);
   
   +++ b/modules/product/src/ProductStorage.php
   @@ -0,0 +1,58 @@
   +  public function revisionIds(ProductInterface $entity) {
   

   Do we really need these new methods on the storage?

2. +++ b/modules/product/src/Entity/ProductVariation.php
   @@ -457,7 +533,8 @@ class ProductVariation extends CommerceContentEntityBase implements ProductVaria
   +      ->setRevisionable(TRUE);
   

   I'm not sure the product ID should be revisionable as it shouldn't really change in theory... But perhaps we could use this to track when the reference is lost/fixed?

I haven't really tested the patch manually, but one of first things I've noticed is the product controller, can't we use the \Drupal\entity\Controller\RevisionOverviewController? Or at the very least the trait offered by Entity API?

@khiminrm Can you look into this?

I agree with Ryan, I don't think it's worth extending another class. The only thing we're currently missing is the RevisionLogEntityTrait that the product is currently not using, all we have to do is use it and add: $fields += static::revisionLogBaseFieldDefinitions.

Introducing CommerceEditorialContentEntityBase is a nice to have, but I don't think we're gaining a lot by introducing it.

@rszrama: Regarding $product->loadReferencedEntityRevisionByTimestamp(), I'm not sure why we'd need that? We usually load a revision by its ID?

It's a convenience function, to be honest. There's no specific need, but it would be convenient for someone trying to understand what the state of a product with all its variations was in the same way we have convenience functions for loading translated referenced entities.

Regarding the default_variation "field", it's computed and therefore shouldn't be marked as revisionable.

@khiminrm Can you adjust this?

Also, if we really want to revision variations, then I think the product should reference a variation revision? Just afraid that'd potentially introduce bugs... A little bit hesitant to go all in with revisions as revisions are costly in terms of DB storage especially for sites with lots of products.

Sorry, I may not have included the instruction above, but to avoid introducing an extra dependency, we decided to focus just on the 1.x comparable feature set of products and product variations being independently revisioned. I'm also concerned about the DB storage implications, but it should be easy enough for sites with large catalogs to disable them by default, right? And certainly to disable them within the variations inline form widget?

Speaking of which ... @khiminrm, we do need the SingleVariationWidget to be updated in conjunction with this patch to add the toggle for whether or not updating the referenced variation should create a new revision. This should mimic the other inline entity form widgets, which have the checkbox in their form widget settings like so:

After installing the patch from @khiminrm in #56 we found that the Add to cart form / button was removed from our product pages. This was due to how the ProductVariationStorage::loadEnabled method was determining if a variation was enabled.

When the loadEnabled method is executed, it loads the variations from the product and generates and array of variation ids:

    foreach ($product->variations as $variation) {
      $ids[$variation->target_id] = $variation->target_id;
    }

But then it attempts to remove any disabled variations by doing a DB query for any variation which is in the $ids array, and has a status of 1, followed by an array_intersect_key of the $ids and the DB query results:

    $query = $this->getQuery()
      ->accessCheck(TRUE)
      ->addTag('entity_access')
      ->condition('status', TRUE)
      ->condition('variation_id', $ids, 'IN');
    $result = $query->execute();
    if (empty($result)) {
      return [];
    }
    // Restore the original sort order.
    $result = array_intersect_key($ids, $result);

The issue occurs because the keys and values of the $ids array are both the variation ID, whereas the result from the DB query is an array with the variation revision ID as the key(s) and variation ID as the value.

I've attached an updated patch which changes array_intersect_key to array_intersect, so that the intersection is done on the array values rather than the array keys.

I've been working extensively on this today and refactored a lot of code:

• Removed the ProductViewsData and ProductEntityViewsData
• Made use of the Entity API revision overview controller (Commere now provides one, which extends the one provided by Entity API.
• I introduced a RevisionRouteProvider which provides routes for revisionable Commerce entities.
• Introduced a CommerceRevisionableContentEntityBase which extends CommerceContentEntityBase so we don't have to duplicate the helpers that are provided by this base entity class.
• Defined generic form classes for reverting a revision and reverting an entity revision for a single translation.
• Defined a generic form class for deleting a revision.
• Refactored the hook_update() added and the post update function (according to this commit from Entity queue https://git.drupalcode.org/project/entityqueue/-/commit/e099b13506f664af...).
• Removed the hook_update_dependencies() which now seems irrelevant and outdated (this update function has been long removed).
• I also decided to remove the extra methods added to the ProductVariationStorage and removed the ProductStorage introduced (there were helper methods for which we have no real need, additionally, these were completely copied from the NodeStorage.
• Some of the additions / changes made in the form classes / revision overview controller made in Commerce should be contributed back to Entity API. For example, noticed different behaviors/bugs compared to the Node overview controller which passes the current language to the operation links. But I currently have no time for that.
• Last but not least, finally understood why we couldn't make use of {commerce_product_variation_revision} and did my best to document this limitation in code (the Symfony route compiler has a limitation of 32 characters for route variables.
• I also took a stab at fixing the current test failures.
• And finally addressed coding standard issues introduced in the various previous iterations of the patches.

Also, the patch was made against 2.x, but I really think that this change can't go in 2.x as it's too risky for existing installations since there are plenty of new database tables created, which means this would definitely affect data migrations for example as well as custom queries.
Additionally, these changes affect JSON API as well. I wouldn't want to risk breaking existing installations and it definitely sounds safer to commit this directly to 3.0.x.

Finally, we're missing tests coverage for the newly added logic. We are at the very least missing a functional test ProductRevisionsTest (I bet we could steal most of the logic from Drupal\Tests\node\Functional\NodeRevisionsTest.

I haven't really thought about eventual new Kernel tests that would make sense to create, but perhaps the Kernel Entity tests?

For future iterations, providing an interdiff would definitely help following the changes, as well as a comment explaning why a particular change is made because it seems obvious that the last iteration of the patch (from comment #62) inherited a lot of code from the early patches which seems irrelevant today.

We might as well miss a setting at the product type level (similar to content types) that determines whether a revision is created by default or not (could be implemented as a followup I guess).

Tests were passing locally, so retried them and they passed.

+1 for 3.x. One concern was this patch landing and sites with millions of products having to dance around this upgrade.

Is Drupal 8 supported on 3.x? If not we can drop commerce_product_update_dependencies to remove the amount of changes.

I think Functional tests are enough over Kernel.

What would be neat is an upgrade test – we can create a small SQL dump before the changes and then run a test to do the upgrade. That'd be nice. Core has this in a few places.

I think anything missing is fine as a follow up once it lands, to match feature parity with revisions on nodes/terms/etc.

Is Drupal 8 supported on 3.x? If not we can drop commerce_product_update_dependencies to remove the amount of changes.

commerce_product_update_dependencies() was already dropped. D8 is not supported by 3.0.x no. In fact 2.x-dev doesn't support D8 either which is as you know no longer supported.

@jsacksick I've created tests for product revisions. Could you review, it please? I haven't created for variations yet. Should be something similar, right?

@khiminrm: That's a good start, however we're missing a few things.

As discussed on Slack, while testing the HTTP status code is good, we don't actually confirm that a product revision is properly reverted.

We need to ensure deleting a revision works as expected too:

For examples, Node does this for testing the deletion:

// Confirm revisions delete properly.
    $this->drupalGet("node/" . $node->id() . "/revisions/" . $nodes[1]->getRevisionId() . "/delete");
    $this->submitForm([], 'Delete');
    $this->assertSession()->pageTextContains("Revision from {$this->container->get('date.formatter')->format($nodes[1]->getRevisionCreationTime())} of Basic page {$nodes[1]->label()} has been deleted.");
    $connection = Database::getConnection();
    $nids = \Drupal::entityQuery('node')
      ->accessCheck(FALSE)
      ->allRevisions()
      ->condition('nid', $node->id())
      ->condition('vid', $nodes[1]->getRevisionId())
      ->execute();
    $this->assertCount(0, $nids);

For testing that a revision is reverted, Node does this:

  $this->assertSession()->pageTextContains("Basic page {$nodes[1]->label()} has been reverted to the revision from {$this->container->get('date.formatter')->format($nodes[1]->getRevisionCreationTime())}.");
    $node_storage->resetCache([$node->id()]);
    $reverted_node = $node_storage->load($node->id());
    $this->assertSame($nodes[1]->body->value, $reverted_node->body->value, 'Node reverted correctly.');

So we need to the same for products (adapted of course with the actual message that's displayed when displaying a product revision).

Also, we have no tests equivalent to NodeRevisionsTest::testRevisionTranslationRevert() that confirms that a specific revision of a translation gets reverted.

And lastly, testing revisions for product variations would be great as well.

I've added additional tests mentioned in previous comment. Still need to create product variations tests.

I've added tests for variations revisions. Also made some code changes for product revisions tests and added some fixes to the patch to fix some errors found during writing tests.
Regarding variations tests I haven't added tests for variation revision view page as there is no canonical view page for variation.
Also there are no tests for accessing revert, delete pages of revisions of different bundles variations as there are no bundle specific permissions as in products. Tested on local to access the pages with use which role has permission to revert, delete specific product bundle revisions and the user doesn't have access to revert or delete variation revision of the same bundle as product. Maybe we need additional fixes in code of the patch. Not sure yet how to fix it properly.

@khiminrm Hi, I have used this #74 patch. I didn't get any errors which is great but I am not sure how to test this? There is no option coming in Drupal admin to revert to the previous version of the product. There is no setting in the admin panel to show product revisions.
Could you please explain the steps or process to test this patch? That would be really helpful. I believe the way we have the revert option for a normal content page, similarly, we should have that for the products as well. Please share more information on this.

Thank you

#2350939: Implement a generic revision UI has been committed.

Although might be worth waiting until #3323788: Revert and Delete actions should not be available for the current revision is resolved.

I don't think the work here needs to be paused until #3323788 is done, that's just a bug fix to one tiny part of the system.

I think it would be worthwhile to identify all of the pieces necessary in the issue summary, including each test scenario we want to cover and whether they're done.

@khiminrm: Were the bugs you fixed as part of #74 things related to the revisions change or existing functionality in Commerce?

Also, should this go into 3.0.x instead of 8.x-2.x?

Related: #3347483: Support product revisions from Commerce v1

FYI patch #74 still applies, but there was a little fuzz on one file so here's a clean reroll.

This was initially targeting 3.x, not really sure why I changed it back to 2.x...

My main concern with revisions is the inability to disable them... On a large project I'm working on, enabling revisions would cause the DB to grow way too quickly...

Also, there's still a data loss concern... Which makes me wonder if we shouldn't instead introduce a commerce_product_revision module, which swaps the Product entity class to one that supports revisions... But... That maybe unrelastic as there's code elsewhere that still wouldn't require changes to account for revisions...

Moving to v3.

My main concern with revisions is the inability to disable them... On a large project I'm working on, enabling revisions would cause the DB to grow way too quickly...

Following node's workflow, it's not assumed that a change on the node would result in a new revision, that default is controllable per content type. So why would this be any different?

Well, what I meant (sorry if I was unclear) is that even if you're not planning to use revisions, the data model is still affected regardless.

Which means, duplicate revision tables for fields, for the main table as well (i.e commerce_product_revision). That surely has a non neglible impact on performance.

I wouldn't like having to suddenly worry about this on the relatively large sites I'm currently maintaining.

The content type setting doesn't have any impact on any of that. (it just drives whether a new revision is created on save).

Ok, ISWYM.

#74 works for me. One thing that I would like to add is the relationship of the view between revision and the actual entity. It was not covered by CommerceEntityViewsData so I've added some changes for it to work the same as it was done in the EntityViewsData.
Interdiff is not working, changes were added at the end of the patch.

@jsacksick Re #84 wouldn't that mean that Drupal already has a by far larger issue with performance and revisions, as it uses nodes and they are revisionable?

What I read here is:

We're afraid of the revisions database structure, that is used for nodes ever since?

Do I get that right?

Wouldn't then any large project, using nodes, make a wrong pick with Drupal?

Just playing Devils Advocate ;) To clarify things.

Currently using a patch in #87 which does work but the time stamp and author is always the same.

Based on the node behavior, this patch below adds a moderation handler to the product entity.

Patch on #60 currently fails against latest commerce release 2.37.0

I've tested locally. I think we can move it to "Needs review".

Patch with the latest changes from MR

The fork needs to be updated and conflicts needs to be resolved. Anyway, this looks quite far implemented. Thank you @tBKoT for pushing things forward.
#2350939: Implement a generic revision UI and #3323788: Revert and Delete actions should not be available for the current revision are both resolved in core. So this should be compared to what https://www.drupal.org/node/3160443 suggests.

Maybe "Needs tests" tag can be removed, I can see the MR has tests, but that needs to be checked in detail.

I think there are quite a few projects where it would be great to have revisions for products and product variations to be able to track changes and revert them if needed!

Made the title reflect the implementation.

Rebased it. Let's see what the tests say.

Ok, seems like this some test inside "ProductLayoutBuilderIntegrationTest" fails for the next major drupal release.

Back to needs work.

Tests succeed again, after rebasing on current 3.0.x-dev!

This issue just came up in Slack again: https://drupal.slack.com/archives/C1TLCCF9B/p1724339226822049

There is still no final decision, whether this issue will ever see the light of day, but it definitely won't be 3.0.x.

The current state of this issue branch add revision support for both products and product variations. There were some discussions earlier inside this issue and slack, whether to only support revisioning products, but at least for our use case, we'd need revision support for both products and product variations.

The current MR currently doesn't include the typical "Create new revision" checkbox used on most revisionable entities:

Hence, I am setting this back to needs work.

An even better approach mentioned by @jsacksick over @Slack would be to be able to opt in to revisioning when creating a product- / product-variation-type. This seems to be the way forward, if we want this feature getting merged in future 4.x / 5.x releases. But that's not straight forward, as this feature isn't currently supported by Drupal "out of the box" and (might) need a lot of work.

Hi tbkot #94, Patch doesn't work on latest commerce version an dev version as well

It would be great if we could set how many revisions are kept, sites with a large product database could end up with very large revision tables. Allowing to set a cap would be a good solution for this.

@c_archer There's A Module For That, e.g. https://www.drupal.org/project/revision_cleanup or see the list of modules on this page https://www.drupal.org/project/node_revision_delete

I merged the branch and worked on making it able to set the default for revision for product types.

I tested this on our environment and it seems to be working as expected.

It seems it doesn't save the default revision state from the settings, so it need some new logic, ill continue working on this.

I've worked on the setting the revisions by default and it seems to work for us now.

Patch for the 3.0.2 tag

@rowrowrowrow The 2656896_3.2.0.patch is empty.

Whao, this is a heavy one. Because many files are changed, I think someone should review this asap and the Commerce Guys should decide how to proceed here. In the meantime perhaps the two tags
Needs tests, Needs issue summary update
could be resolved?

I won't have the time in the near future, but still think this would be a very helpful option for those who need it!

Code changes look good to me in merge request https://git.drupalcode.org/project/commerce/-/merge_requests/243 . I fixed the phpcs and phpstan fails.

The change is quite big in general, so might only be something for Commerce 4.x?

Test coverage looks ok to me and we have the basics tested here.

I also updated the issue summary.

Any updates on this feature?

For some reason I can't merge 3.x into this branch even though it says I should be able to. Can someone do it?

It merged cleanly for me.