Sharing instances of apps and groups

[aldbr]

First approach

• the state of the instances and groups is compressed and appended to the URL
• problem:
  • we can potentially quickly reach the URL max length
  • we can't select the apps and groups we want to share
  • we can't add the instances and groups to an existing "workspace"

Second approach (from @TheauW)

• the state of the instances is stored in the session storage (URL is not used anymore)
• there are 2 new buttons:
  • one to export selected instances and groups as a JSON blob
  • the other to import a JSON blob that is then appended to the existing "workspace"

On May 15th 2025, the second approach was presented and we get interesting comments:

• it's not intuitive (a URL would be appreciated)

• one could potentially make a mistake in the produced JSON while copying/pasting it

• other potential problems:

  • if you don't save the JSON blob somewhere and lose your session, then you have to build your dashboard from scratch again

Based on the comments, we could come up with a potential long-term plan to help mitigating the issues.

Ultimate approach?

The approach would include web-specific routes in diracx (new dbs and routes).

We would have 2 different objects:

• workspaces: long-lived and editable dashboard composed of groups and sub-app instances, owned by a given user.
• snippets: immutable snapshot corresponding to a subset of a workspace that can be shared (and expired at some point).

As a user, when you log in diracx-web, you can:

• get your workspaces (GET /api/web/workspaces)
• modify one of your workspace (PUT/PATCH /api/web/workspaces/{workspaceId})
• create a new workspace (POST /api/web/workspaces)
• delete one of your workspace (DELETE /api/web/workspaces/{workspaceId})

You can also:

• export a snippet by selecting the instances and groups you want to include (POST /api/web/snippets body:JSON blob)
• import a snippet in your current workspace (GET /api/web/snippets/{snippetId}) - you could potentially even choose which part of the snippet you want to import.

I think it would solve most of the problems:

• users can save and easily retrieve their workspaces if they need
• snippet can be shared with a simple id, avoiding the risk of potentially copying pasting a malformed JSON blob

But it also tightly binds diracx-web with diracx (which is likely fine as long as we don't spread web-specific elements throughout diracx)

[aldbr]

Proposal: User-dashboard + Snippets

Based on the discussion in this issue, here's a simplified approach that covers the use cases without the complexity of full workspace CRUD.

Core idea

Instead of multiple workspaces per user, use a single persisted dashboard blob per user (the "user preferences store" pattern). The backend doesn't interpret the content — it just stores and returns JSON. All structure and interpretation lives in the frontend.

For sharing, snippets provide immutable, expirable snapshots that resolve as URLs.

Backend: 2 tables, 4 routes

Route	Purpose
GET /api/web/user-dashboard	Load dashboard state
PUT /api/web/user-dashboard	Save dashboard state
POST /api/web/snippets	Create shareable snapshot from selected items, return an ID
GET /api/web/snippets/{id}	Fetch snapshot for import

Tables:

• user_dashboard: user_id, dashboard_json, updated_at
• snippets: snippet_id, data_json, created_at, expires_at

Frontend behavior

• On login: GET /api/web/user-dashboard — if empty, default to "Job Monitor"
• On dashboard change: PUT /api/web/user-dashboard with the full blob
• Share: user selects items → POST /api/web/snippets → gets a URL like /s/{snippetId}
• Import: open snippet URL → GET /api/web/snippets/{id} → preview → copy selected items into own dashboard (it's always a copy, no shared mutable state)

Snippet expiration

Snippets have an expires_at field. A cleanup job periodically removes expired entries. This keeps the table from growing unbounded.

Why this over the "ultimate approach"

Since users have one dashboard (not multiple workspaces), and importing a snippet creates a copy (no shared state), full workspace CRUD with access control is unnecessary. This approach gives:

• Persistence across sessions (no more losing your dashboard)
• Shareable URLs (addressing the main user feedback)
• Minimal backend surface (2 tables, 4 routes, no schema coupling to frontend evolution)
• Room to grow — a real /api/web/user-settings can be added later for preferences like theme/locale without naming collisions