Version History for Devices

[joepavitt]

Description

Follow on item from: #4509

Create the Version History view for Devices

Tasks

Preview Give feedback

1. API Add a devices/:deviceId/history API endpoint #5090
2. UI Version history for devices UI #5107
3. Improve Device Audit Log Events #5111
   1 of 6
   size:M - 3 task +2
   

Epic/Story

No response

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[cstns]

I think i got the gist of things on why the device timeline would be a bit harder to implement.

Project AuditLog events are pretty straight forward, having the polymorphic relation point straight to the project/instance:

flows.set
project.snapshot.imported
project.snapshot.rolled-back
project.snapshot.created
project.created
project.settings.updated

Device AuditLog events are scattered between:

• devices (events reference the device and deviceId as entityType and entityId and are pretty straight forward to implement)

settings.update ??
flows.set
device.assigned	
device.credential.generated
device.developer-mode.disabled
device.developer-mode.enabled
device.remote-access.disabled
device.remote-access.enabled
device.restarted
device.settings.updated

• teams (events reference the team and teamId as entityType and entityId)

team.device.assigned
team.device.bulk-deleted
team.device.created
team.device.credentials-generated
team.device.deleted
team.device.developer-mode.disabled
team.device.developer-mode.enabled
team.device.provisioning.created
team.device.remote-access.disabled
team.device.remote-access.enabled
team.device.unassigned
team.device.updated

• applications (reference the application and applicationId as entityType and entityId)

application.device.assigned
application.device.snapshot.created
application.device.unassigned
application.deviceGroup.members.changed

• instances/projects (reference the project and projectId (hashed) as entityType and entityId)

project.device.assigned
project.device.unassigned
project.snapshot.device-target-set

There might be more, these were taken from my local db, some actions could be missing because I couldn't trigger them or didn't know how to trigger them.
They are a result of

SELECT DISTINCT event FROM AuditLogs where event like '%device%';

Because we don't have a direct device reference for team.device.xx, application.device.xx, application.deviceGroup.xx, project.device.xx and project.snapshot.device-target-set, correlating these to the device in question (as we stand) would be costly at best if not impossible. Most of them reference the device in the body of the entry which is a TEXT type that stores a json payload.

The main problem we have is that we can't correlate team, application and project device events to the device itself. The way I see it, there are a couple of ways to go about it, each with it's own drawbacks and advantages.

1. we could stick to only device.xx events for which we have a direct relation to the device
   • this would paint/render an incomplete history/timeline
   • easiest to implement and complies to the iterative approach and we could include on the other events on a later date
   • no impact whatsoever on the team audit log
2. drawing a line and saying that starting from this point forward your timeline will be complete and double down on team application and project device events and add device.xx events as well (adding device.xx events for each team, application, project device events)
   • easy to implement
   • would make a mess of things with the team audit logs onward (we'd have duplicates and multiple entries for the same action but from different reference points)
   • would have an incomplete history for devices up to this point
3. doubling down on existing team, application and project device events in order to back fill device history via a cron job to traverse all team, application and project device events and insert backdated entries for device events (should be a batched job as it could lock the AuditLogs table)
   • harder to implement
   • robust and backdated history/timeline for devices
   • the team audit logs would get duplicate entries from different perspectives of the same action

Moving forward with either pt. 2 or 3, a correlationId would be beneficial on the AuditLogs table that would allow grouping of events (at least on the team audit logs view). This could be a hash comprised of the concatenation of requestId + session.sid + dateTime which can be set on the request and used across the process when auditLog entries are created.

[knolleary]

I think we move foward with option 1 to get the basic api and UI in place. We then formulate a plan to address 2/3 as a follow on (rather than try to solve them before making progress on 1).

I don't have an immediate suggestion on solving 2/3 - will need to digest and think about it some more.

[joepavitt]

The key piece of information we care about for the Version History view is just when new flows are deployed to a Remote Instance, which I'd assume is always flows.set? Although I'm now assuming that when Instances/Applications have target snapshots assigned, that doesn't necessarily fire a flows.set?

[joepavitt]

The events we need to understand are always going to be flows.set, but it's important to communicate to the user why this happened. We have a few ways by which flows can be deployed to a Remote Instance:

• Instance is in Dev Mode, and the user has explicitly clicked "Deploy" inside the editor
• DevOps Pipeline: Pushed from one stage to another
• Instance Target Snapshot: Remote Instance is bound to a Hosted Instance, and the target snapshot has been set and rolled out to the Remote Instance.
• Snapshot Rollback: user has chosen an old snapshot to re-deploy to the Instance

If we have an event for each of these four, then we are golden.

You can read the events that were used for Hosted Instances here: #4424 (comment)

[joepavitt]

The version history view should only be showing the following events:

• Manual deploy - flows.set
• Pipeline - application.pipeline.stage.deployed - this currently triggers at application level, and not necessarily reliant, needs further investigation
• Instance Target Snapshot - ``
• Snapshot Rollback: application.device.snapshot.device-target-set
• Snapshot Created: ``

Please can you identify the gaps here and detail explicitly which audit log events correlate to these things happening on the Device.

[cstns]

opened https://github.com/FlowFuse/security/issues/100 for the audit log security issues

[cstns]

The version history view should only be showing the following events:

* Manual deploy - `flows.set`

* Pipeline - `application.pipeline.stage.deployed` - this currently triggers at application level, and not necessarily reliant, needs further investigation

* Instance Target Snapshot - ``

* Snapshot Rollback: `application.device.snapshot.device-target-set`

* Snapshot Created: ``

Please can you identify the gaps here and detail explicitly which audit log events correlate to these things happening on the Device.

Current state of affairs:

• manual deploy:

  • event: flows.set
  • reliable, direct correlation with the device

• deploying through a pipeline:

  • events: application.device.snapshot.device-target-set or team.device.updated
  • the events are bound to the application and team respectively

• deploying through an instance

  • event: project.snapshot.device-target-set
  • the event is bound to the instance

• snapshot rollback:

  • event: team.device.updated or application.device.snapshot.device-target-set
  • can only be triggered when the device is assigned to an application
  • the events are bound to the application and team respectively

• spanshot created:

  • event: application.device.snapshot.created
  • can only be triggered when the device is assigned to an application
  • the event is bound to the application

Other than the manual deploy event we don't have anything registered on the device itself. For an mvp we could at least insert a device audit log event starting from this moment onward when these project/team/applications events are triggered so users can at least actively keep track of their device flow changes.

Backtracking these would be worth it on the long run but it would need careful implementation.

[joepavitt]

We could at least insert a device audit log event starting from this moment onward when these project/team/applications events are triggered so users can at least actively keep track of their device flow changes.

Agreed, but separate PR please as a follow up as to not block this.

[joepavitt]

Closing this out as the primary task has been completed. Follow up item with #5111 has been created for next Milestone