Large entries in audit log

[Steve-Mcl]

Current Behavior

Following addition of support for multiline env vars #4069 it was noted that imports of large fields cause rather large audit log entries.

Example (zoomed out on a 4k monitor):

Expected Behavior

We should either drop logging of before and after values, log keys changed only or log a summary of changes

Steps To Reproduce

import large env file or add several large env vars to an instance/device

Environment

• FlowFuse version: current/prod

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[Steve-Mcl]

Design

I propose we approach this from the view of Env Vars (where the issue was raised) rather than a general/overall logging update since I believe there are unique properties e.g.

• Env Vars are an array of objects meaning we get audit entries like env[1].name change from 'no_proksy to no_proxy'
  • This would read much better as Env 'no_proksywas renamed tono_proxy'`
  • Since we know the structure of the internal env vars, this becomes an easier (but bespoke) task
    • If handled correctly, we could provide a resuable pattern for log formatting array of object containing name/value props (food for thought)
  • Currently, when there are multiple Env Vars changes (like for an upload) they are all in one long unreadable line. Investigate possibility/suitability of multiline output for better readability
  • Lastly, as ENV VARS could potentially contain sensitive info or be super super long, it is not ideal that these are stored in the audit log and reproduced for all to see at a glance.

Example Before:

Proposal 1 mock up:

• No values stored or revealed
• Detected changes are listed in a fixed, descriptive format as opposed to a blob of text
• A mono spaced font is used to help with layout and readability.

Proposal 2 mock up:

[knolleary]

There are certainly other places where the way the audit log captures all before/after state and reports it simply doesn't scale. The new edit snapshot log entries is another case - where we log the full before/after description - which could be multiple paragraphs of text.

We don't want to have to fix each case individually; the default formatter for changes should just do a better job of it. I think hiding the specific changes by default is a good step. Then showing changes in a more structured way - rather than fully inline.