I want a strategy for keeping a history of changes that my app makes to its own entity properties. I might need to roll back changes that the app has made in error, and a customer might simply want to know what changes were made over time.
Do you have a strategy that you could recommend, or at least describe?
Hey @mikeroyal. From my cursory look at that add-on, it doesnāt not purport to report on changes to issue entity properties.
@david.pinn I assume by changes you mean changes to the data stored in the entity property itself, i.e. the values the app stores. We have been looking into how to track schema changes to our entity properties, such that we can handle changes to the data structure of entity property data over time - but I believe this is not what you are referring to.
Yes, you have the gist of it, @tbinna. There are multiple motivations for keeping some kind of history, of which changes to the scheme of the stored data is one. If a release goes wrong, for example, we need to be able to roll back to an earlier version of the data. Beyond that, though, weād like to offer our customers the ability to view changes to their data over time.
@david.pinn
Are you thinking of versioned entity properties, similar to page content versions for Confluence? We are also interested in approaches to achieve this.
Yes, @marc, at this moment, Iām thinking of associating a schema version with each entity property. Whenever we do a release that changes the schema, we will keep a backup of any existing value at that time; that way, we can roll back to a known good state if necessary. Weāll probably keep a history of about 10 such backup versions. It also means that we can work with a legacy schema if we donāt automatically migrate all data at the time of the release of a new version of our product.
As a separate matter, weāre considering keeping a history of changes that the user makes to their data, stored as entity properties. For that, weāll need to associate not just a schema version, but also a data version with each entity property. By my calculation, we can store a history of about 50 changes to our main entity property (a risk assessment) without blowing the entity property value size limit of 32768 bytes. I need to do some more thinking about when we write to that history: is it written automatically at every change that the user makes, or will we let the user determine when to explicitly save a ābaselineā?
Would you share any thought that you have?
Hi @david.pinn ,
The problem we are facing is that our app uses multiple entity properties. These depend on each other, and we need to update multiple entity properties in one ātransactionā.
This usually works fine, however not always. So if we had history state in the entity properties, we could āroll backā to a known correct state. As the entity properties have a version number, that is a feasible approach.
At the moment we donāt have a solution.
Although I donāt know the whole story, my instinct would be to create a new entity property that combines the multiple other entity properties, and switch to that new combined version. Maybe remove the legacy separate entity properties when you determine that the switch-over has been successful.
Hi, I also thought about issue entities history, even reported a feature request: https://ecosystem.atlassian.net/browse/ACJIRA-2057?filter=61970
If, as vendors, we could tell Jira to log changes to issue properties, then those changes would be displayed in Issue History for debug purposes or maybe even available using REST API