Set up dashboard version history api

[liyiy]

Changes

Set up versions API for #3551

The dashboard insight page is dependent on some of the filter work going on right now, so I'm skipping to the version history in the meanwhile. This is just a basic setup so that I can also start putting it together on the frontend

A version is created whenever:

• a dashboard item is created
• a dashboard item is updated

Previous state is set so the user can "roll back" to a previous version of the updated dashboard item. Otherwise it's empty (there's no previous state to a newly created object)

Checklist

• All querysets/queries filter by Organization, by Team, and by User
• Django backend tests
• Jest frontend tests
• Cypress end-to-end tests
• Migrations are safe to run at scale (e.g. PostHog Cloud) – present proof if not obvious

[liyiy]

I am still new to Python and Django, so please feel free to critique away! It will help me learn faster 😀

[timgl]

Wouldn't it be a lot simpler to add a 'parent' primary key to DashboardItems, so we can create a chain of version history you can go backwards/forwards in?

[liyiy]

Wouldn't it be a lot simpler to add a 'parent' primary key to DashboardItems, so we can create a chain of version history you can go backwards/forwards in?

That does sound simpler, but just some clarifying questions then:

When we update a dashboard item, are you saying that we should create two dashboard items out of it and set the original as the parent of the updated? And then if we're looking up the entire history of a dashboard item, wouldn't we be continuously looking up the parent of each dashboard item? (this one I'm a little confused about)

Also, the version history mocks include commenting, I don't know if we'd want to tack that onto dashboard item too?

However, I understand that storing a whole state in a key is not ideal, perhaps that previous_state key could be a previous_instance key that links to the parent dashboard item instead? But then we'd really be creating a new dashboard item every time we're "updating" instead of actually patching over it, in order to maintain its previous state in the database. And then we'd have to point that original dashboard item we're "updating"'s key to the newly created one instead 🤔

Let me know if I'm understanding things correctly or not 🙂

[timgl]

I'm not wedded to my approach but it seems easier than copying the state in another object, and we're already creating new DashboardItems any time a user changes something (minus the parent part)

When we update a dashboard item, are you saying that we should create two dashboard items out of it and set the original as the parent of the updated?

Something like this

• DashoardItem Reports that users will need #1
• User adds filter, create DashboardItem Mapping xpaths to our product #2 with parent=1
• User adds another filter, create DashboardItem /Actions (Log / Graph) #3 with parent=1

And then if we're looking up the entire history of a dashboard item, wouldn't we be continuously looking up the parent of each dashboard item?

You'd be able to get the entire history by looking up all DashboardItems that have parent=1

Also, the version history mocks include commenting, I don't know if we'd want to tack that onto dashboard item too?

I think this could be a InsightComment model that links to the parent dashboarditem.

[liyiy]

I'm not wedded to my approach but it seems easier than copying the state in another object, and we're already creating new DashboardItems any time a user changes something (minus the parent part)

When we update a dashboard item, are you saying that we should create two dashboard items out of it and set the original as the parent of the updated?

Something like this

• DashoardItem Reports that users will need #1
• User adds filter, create DashboardItem Mapping xpaths to our product #2 with parent=1
• User adds another filter, create DashboardItem /Actions (Log / Graph) #3 with parent=1

And then if we're looking up the entire history of a dashboard item, wouldn't we be continuously looking up the parent of each dashboard item?

You'd be able to get the entire history by looking up all DashboardItems that have parent=1

Also, the version history mocks include commenting, I don't know if we'd want to tack that onto dashboard item too?

I think this could be a InsightComment model that links to the parent dashboarditem.

This makes sense! Thanks

[liyiy]

Closing to implement changes on #4395 instead