feat: multiple profiles (named configuration slots)

[mairas]

Motivation

Let a user keep several full KIP configurations (dashboards, widgets, theme, units) on the Signal K server and switch the active one per device — e.g. a helm layout vs a cockpit layout, or per-crew setups. Profiles are user-scope Signal K applicationData, so they need a real per-user identity.

Relationship to the authentication PR

This PR includes the commits from #1091 (same-origin cookie/SSO authentication). Profiles build on it: user-scope applicationData needs the per-user session that work provides. If #1091 merges first, this branch can be rebased to show only the profiles diff; as submitted it contains both.

Approach

• A ProfileService owns the lifecycle — list / switch / create / rename / duplicate / delete / import — on the user scope, with name validation (URL- and JSON-Patch-safe charset, reserved default, no duplicates) and guard rails (can't delete the active, the last, or default; switching verifies the slot still exists; import rejects an unsupported config version).
• The active profile name and the per-device "remote control" identity live in a per-device connection config (its own schema version, migrated once from the previous in-profile location), so switching a profile never changes which display a screen is or whether it participates in remote control.
• A Profiles section in the Configurations tab. Write actions are gated on write capability — a read-only session can view and switch but not mutate.

Testing

Unit tests for ProfileService CRUD + guard rails, the connection-config migration (all branches), storage write-safety/queue-failure reporting, and the read-only write gating. Same jsdom pre-existing-failures note as #1091.

🤖 Generated with Claude Code

[mairas]

This is what multi-profile settings look like. You always use the same session-provided login. The profiles are per-user and you can switch between them and modify them as needed via Settings.

[tkurki]

While the current method of "configurations are one per user" method works to an extent it is a bit too big a hammer for the job - it is not KIP specific, so switching to another user means that also other application's serverside stored settings are switched. Settings are device and orientation specific, while a user's access level and other settings, such as unit preferences, are per the (human) user.

So to me this looks like a welcome addition and at the right granularity.

I have also struggled with managing KIP dashboards for portrait and landscape tablet orientations, as logout-login dance when you rotate the device is pretty unconvenient. Afai understand this would solve that, allowing me to have multiple dashboard sets?

[godind]

Hi Teppo and Matti,

I agree that device-tied configuration should be added. FYI I'd rather call those Layouts as Profiles generally refers to users. I have not looked at the implementation details yet, as I am working through another batch of PRs first, and this one is a large change. Since the PRs were opened before we had a chance to discuss the plan, this is only initial, high-level feedback based on the PR description and the single screenshot.

same-origin cookie/SSO authentication feedback

I would like to preserve the following existing use cases. At this stage, it is not yet clear to me that this PR keeps them:

1. For boat owners or companies renting boats, there may be an admin account for the owner or fleet manager, and a separate lessee account with R/W or read-only rights to protect the Signal K setup. A permanent nav station device should allow easy switching between those accounts. At the same time, lessees and their passengers should be able to load KIP on their own devices, such as phones and tablets, all using the lessee account without issues.
2. For boats with racing crews, there may be an admin account for the owner and multiple separate R/W accounts for crew members, so each person can manage their own KIP iPhone layout. All users, on their own devices and with their own accounts, should be able to log in to the same server at the same time without issues.
3. For boats with fixed KIP dedicated devices, such as a mast display or a helm KIP MFD, it should be possible to auto-login with a user that has only read-only or limited R/W access. That way, if someone on that device reaches the Signal K admin page, they still do not get admin access and cannot alter the Signal K server setup, while the nav station below can remain logged in as admin at the same time.

I personally use an old iPhone that auto-logins with an R/W account and loads a single AP widget dashboard. It acts as my AP remote control, and users should not be able to access or change Signal K server settings from it. It is a dedicated remote, and that was one of the original reasons I started using Signal K and contributing to KIP.

multiple profiles feedback

By removing the ability to use Global scope as shared storage, the only remaining way to copy configurations between users is to export to a file, switch user, and then import the file.

I understand that exposing Global scope makes the UI more complex. Still, removing it also removes a useful feature. Maybe there is a better way to improve the UX without losing that capability. KIP configuration management already has fairly weak UX as it is.

On Teppo’s comments

Settings are device and orientation specific, while a user's access level and other settings, such as unit preferences, are per the (human) user.

In most computer networks, when you log in with an account, access level and user preferences such as regional settings, units, and home folder follow the account, not the device. That can be tuned or disabled, but it is the common model. Hardware-specific settings stay with the device. The KIP layout is not black and white. It's not a hardware-specific settings, but it is a configuration that is heavily impacted by it, when aspect ratio changes.

I have also struggled with managing KIP dashboards for portrait and landscape tablet orientations, as logout-login dance when you rotate the device is pretty unconvenient. Afai understand this would solve that, allowing me to have multiple dashboard sets?

I do not think this PR solves that directly. You would still need to switch Layout if when the device orientation changes you want a different layout, or you would manually go in settings/options/configuration and load another Layout - which is as much a headache in my opinion.

The real problem is not the layout itself, but the grid model design and aspect-ratio change. If we want to keep widget aspect ratios stable when orientation changes, the grid must add or remove columns and/or rows. That means dynamically changing widget col/row spans and repositioning widgets, which causes visible layout shifts in the sense that widgets are forced pushed out of rows/col. The end result is some rows or columns can end up partially empty and some widgets change location.

I think dynamic orientation switching without visual side effects is impossible. At least so far I have not found a way to do it. You hated the Chartplotter mode layout shift from portrait to landscape but it's a solution that does not destroy legibility and usability, but it shifts FSK/dashboard split from vertical to horizontal.