When you work on product data in the PIM, you probably have some concerns like…
What happens if I make a mistake?
What happens if the manufacturer changes its mind?
How can I find out who changed this piece of product data?
Rest easy, my reader.
Akeneo has both a history and restore option that helps you understand what changed and when as well as how to undo it.
Version history tracks the changes on various entities in Akeneo to show the history of changes to a product. This is incredibly valuable documentation for product changes that will help you preserve previous versions if you need.
Below is a view of a demo product on the version history. You can quickly see the number of versions, the author, what changed and when.
Want to roll back a change? Click restore. Voila.
Check out Akeneo’s documentation on restore.
Feels like magic, but what happens in the back end? And what limitations come with this approach?
As of version 4.0, Akeneo stores previous versions of supported entities in the pim_versioning_version table in the database with the following fields:
Id
Author: (username of the user who made the change)
resourceName: (Entity, in this case Product) But the full list is below:
resourceId: (id of the record in the relevant Entity db)
Snapshot: array of current values
Changeset: array of only changed values
Context: additional information on job/process that caused the change
Version: current number of revision to specific item
Logged_at: Timestamp of change
Pending: Answer Pending based on tech team
Akeneo stores Changeset and Snapshot as normalized PHP arrays in the database, which allows for easier PHP array comparisons. A drawback to this is additional processing to export data using JSON or some other data type from these columns requires converting it back to PHP and then to whatever type you need.
COMMON PAIN POINTS AROUND VERSION HISTORY
There are some important limitations to version history.
Default Flexibility and REQUIRED Serenity settings:
Akeneo Cloud editions have a default version history length of 90 days. After that, a console command pim:versioning:purge --more-than-days 90 --no-interaction --force runs via cron job. You can change that on Flexibility, but not on Serenity. 90 days should be plenty, but it’s something to consider when evaluating your PIM requirements. Be sure to discuss this in the early stages of evaluating the appropriate version of Akeneo.
Version history can get very large:
On a very large PIM implementation, the size of the version history table can very quickly take over most of your free space if you disable the version history table or do not properly plan for the size of your PIM server.
Internal Usage Only:
There is no natively supported export of audits for versioning, so you are limited to the individual entity view page. In other words, you can only view the history of a single product and cannot search with filters of a modified attribute. There are some possible customizations here that we can help you estimate and explore, but only if you are on the Flexibility platform.
Version History only supports the following entities:
- a. Channel
- b. Locale
- c. Category
- d. Group
- e. Product
- f. Model
- g. Association Type
- h. Attribute
- i. Attribute Group
- j. Family
- k. Job Instance
The above list helps for any of these entities but excludes a few with some important implications. Reference Entities and Assets are not supported, meaning changes to those records will not have a rollback feature, user audit record, or any of the other version history features. For example, if you change which reference entity a product attribute is assigned, it will be viewable in the interface:
But if you change the label on the reference entity:
There is no way to show that change on the reference entity record or on the products that have that entity assigned. Assets behave in a similar way, where changes to the individual asset do not register a version history but will affect how assets are viewed downstream.
Have any additional questions? Feel free to reach out to us!
