Add live data split view tutorial

[mjamescompton]

Summary

References #7346

Changes

• Update users store field mask
• Update live view button stying
• Add Live view tutorial

Testing

Steps

View a gateway or application
Live view tutorial should be visible
Click the x to close the tutorial
Opening the page again will cause the tutorial to be visible again
Click either try it or got it to make the tutorial hide for ever.

Results

Screen.Recording.2024-12-04.at.14.18.16.mov

Regressions

...

Notes for Reviewers

Closing the tutorial, then opening and closes the live view causing the tutorial to show again. Show opening the live view make the tutorial hide for ever or should we wait until someone clicks got it or try it.

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Testing: The steps/process to test this feature are clearly explained including testing for regressions.
• Infrastructure: If infrastructural changes (e.g., new RPC, configuration) are needed, a separate issue is created in the infrastructural repositories.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[ryaplots]

I think it makes sense that if the user opens the split view, the tutorial disappears forever, because it's basically the same action as "Try it".

See my comments below.

[pierrephz]

@mjamescompton here is my review regarding the design of that feature:

https://www.figma.com/design/7pBLWK4tsjoAbyJq2viMAQ/console?node-id=6608-16341&t=aXv5IH07ZWfRBo8g-1

DM me for any question

[nicholaspcr]

More or less the same comment left in this PR.

Suggested change

	case "console_preferences.tutorials.seen":
	case "console_preferences.tutorials":

Wouldn't this be enough to update the Tutorial subfield of ConsolePreferences?

I'm writing this but I didn't validate how the fieldmask is created on the Console side of things.

It could be that it is too annoying to make it so every subfield has its fieldmask shortened to its parent's fieldmask, something like console_preferences.tutorials.seen -> console_preferences.tutorials.

If so then it might be worth it to adding the console_preferences.tutorials.seen and the other fieldmasks on the referenced PR.

[mjamescompton]

@nicholaspcr see the last to commits for the required changes to shorten the field mask from the console side.

By default we don't set the field masks they are derived from the data sent by this function Marshaler.fieldMaskFromPatch so thats why it can be confusing to know what field mask is expected without reading the go code when it is developer preference when not to use the default.

I'm leaning towards lets do this on the backend instead of the frontend @ryaplots what do you think?

[ryaplots]

It could be that it is too annoying to make it so every subfield has its fieldmask shortened to its parent's fieldmask, something like console_preferences.tutorials.seen -> console_preferences.tutorials.

Like Michael said, we have this Marshaler.fieldMaskFromPatch function that derives the fieldmasks from the patch. To make Nicholas' suggestion work we would need to refactor this function to default to the parent fieldmask, however, I get the impression that that would not work for every case, because I believe there are fields that expect a more specific fieldmask in the backend, so we would have to adapt this specific fieldmask, like the in the commits Michael mentioned. I think we shouldn't start adapting the fieldmasks for every case, they should be streamlined.

So, I agree with adding console_preferences.tutorials.seen and solving this in the backend.

[nicholaspcr]

I see.

Indeed it makes more sense to have it handled on the backend, specially since this is the standard and it is not hard to do it there.

---

The suggestion I would make regarding the backend changes would be to have the logic handled updates of subfields.

Suggested change

	case "console_preferences.tutorials.seen":
	case "console_preferences.tutorials":
	updateConsolePreferences = true
	consolePreferences.Tutorials = pb.ConsolePreferences.GetTutorials()
	case "console_preferences.tutorials.seen":
	updateConsolePreferences = true
	consolePreferences.Tutorials.Seen = pb.ConsolePreferences.GetTutorials().GetSeen()

@mjamescompton you let me know if you want to do this or if I should make a separate PR adding this to all UserConsolePreferences fields.