Allow a device to be assigned to application

[Steve-Mcl]

Description

Permit a device to be assigned to an application.

NOTE: Raised in draft to permit other engineers to test - before writing a whole bunch of tests and updating docs.

Notable:

1. permit the agent to start even if the working dir does not exist. Instead of a hard exit, an attempt to generate the working directory is made.
2. adds currentApplication which when set, permits the device to launch node-red - allowing user to modifiy flows.
3. updates the log output to indicate instance or application as device owner
4. only writes necessary parts to file - to prevent the fake application snapshot overwriting users flows edits

Application level device implementation:

• Developer Mode / Remote Access ✅
• Device Logs ✅
• Team Library ✅
• Theme, device name and NR menu links ✅
• Adding device in application view adds device to application ✅
• Newly added device in application view updates status when config is applied to device and it starts up ✅
• Upload Snapshot ❌
• Download Snapshot ❌
• Project Links ❌
• Grouping and settings ❌
  • Module cache for device at application level ❌

TODO (this iteration):

• [x] tests
• [x] docs
• [ ] manual testing combinations - to ensure there are no issues when running older platform with newer agent and vice versa

TODO (next iteration)

• Provisioning Tokens for auto add to application
• Module cache for device at application level
• Support snapshots (upload/download)
• Support grouping
• Group settings (env/modules/etc)
• Project Links (Device links? Concept?)

Related Issue(s)

Devices to be assigned to an Application, without being assigned to an Instance#2619

Checklist

• [x] I have read the contribution guidelines
• [x] Suitable unit/system level tests have been added and they pass
• [x] Documentation has been updated
  • [ ] Upgrade instructions
  • [ ] Configuration details
  • [ ] Concepts
• [ ] Changes flowforge.yml?
  • [ ] Issue/PR raised on flowforge/helm to update ConfigMap Template
  • [ ] Issue/PR raised on flowforge/CloudProject to update values for Staging/Production

Labels

• [ ] Backport needed? -> add the backport label
• [ ] Includes a DB migration? -> add the area:migration label

[knolleary]

In quite a few places with this PR there is pieces of logic similar to:

(this.currentApplication ? 'application' : (this.currentProject ? 'project' : 'none'))

In relation to the discussion on https://github.com/flowforge/flowforge/pull/2621#discussion_r1304446272 , I can see a possible future where the valid states will be.

Assigned To	currentApplication	currentProject
nothing	null	null
Application	<applicationId>	null
Instance	<applicationId>	<instanceId>

Meaning, the presence of application means its assigned to something, and instance tells you if it is a specific instance or not.

Looking at that line of code above, it puts all the weight on whether application is set or not. That matches up with the current implementation of the platform, but would make it harder if we decide to modify the model as I've described.

I think we could safely flip the logic in the device agent to something like:

this.currentProject ? ' project' : (this.currentApplication ? 'application' : 'none'))

I believe that would still behave the same way with the current server implementation, but would also work if we modified things.

Given how many places that bit of logic exists in this PR, I don't know if the logic is sound - but wanted to get your input if this is feasible?

[Steve-Mcl]

Looking at that line of code above, it puts all the weight on whether application is set or not. That matches up with the current implementation of the platform, but would make it harder if we decide to modify the model as I've described.

I think we could safely flip the logic in the device agent to something like:

this.currentProject ? ' project' : (this.currentApplication ? 'application' : 'none'))

I believe that would still behave the same way with the current server implementation, but would also work if we modified things.

Given how many places that bit of logic exists in this PR, I don't know if the logic is sound - but wanted to get your input if this is feasible?

The order of the logic was deliberate and considered but I also understand your point.

I will go through both ends again and determine the side-effects of changing (if any).

Watch this space.

[Steve-Mcl]

I think we could safely flip the logic in the device agent to something like:

this.currentProject ? ' project' : (this.currentApplication ? 'application' : 'none'))

I believe that would still behave the same way with the current server implementation, but would also work if we modified things. Given how many places that bit of logic exists in this PR, I don't know if the logic is sound - but wanted to get your input if this is feasible?

The order of the logic was deliberate and considered but I also understand your point.

I will go through both ends again and determine the side-effects of changing (if any).

Login order changed in 1026df4 and verified locally.

It did throw up an issue which has also been resolved on the platform repo.

Ready for re-review now.