Projects
A project is the unit of authored work. One gateway hosts many projects; each has its own views, scripts, named queries, pipelines, assets and runtime identity binding.
What a project owns
| Owned by the project | Shared across the gateway |
|---|---|
| Views (operator screens) | Connections |
| Client and Gateway scripts | The tag namespace and bindings |
| Named queries | User-defined types |
| Pipelines and their execution history | Alarm definitions (attached to tags) |
| The asset/file tree | The file library |
| Its LiveView access policy and identity binding | Platform users, roles and permissions |
| Its gateway variables, unless declared global 1.0.8 | Gateway variables declared global |
| Its login logo 1.0.8 |
Gateway variables became project-scoped in 1.0.8: a variable belongs to the project that created it, and is purged, backed up and exported with it, unless it is declared global. Variables that existed before the upgrade became global, so nothing that already read them changes. → Variables
The split is deliberate: the plant model is one thing; the applications built on it are many. Two projects can present the same tags to different audiences without duplicating the namespace.
Naming
| Field | Rules |
|---|---|
| Name | The URL slug. Lowercase letters, digits, - and _; must start with a letter or digit. No spaces. Immutable in practice — it appears in every LiveView URL. |
| Title | Free text, shown in the interface. Change freely. |
| Description | Free text. |
The name becomes the first path segment of every runtime URL:
https://qubiq.example.com/line1-hmi LiveView home
https://qubiq.example.com/line1-hmi/login runtime login, when identity is bound
Choose it as carefully as you would a hostname.
Lifecycle
| State | Effect | Permission |
|---|---|---|
| Active | Normal. Pipelines run, LiveView serves. | — |
| Disabled | Pipelines stop, entry is blocked, all data is retained. Fully reversible. | Manage Project |
| Trashed | Removed from the project list, retained for 30 days, then eligible for permanent deletion. | Manage Project |
| Purged | Permanently deleted. | Manage Project |
| Deleted | Immediate deletion, bypassing the trash. | Delete Project |
Disabling is the right tool for "take this offline, keep everything" — an out-of-service line, a project pending review, a commissioning environment. Trash is for "I believe this is finished" with a safety net.
Permissions
| Action | Permission |
|---|---|
| See the project list and open a project | View Projects |
| Create a project | Create Project |
| Edit name, title, description | Edit Project |
| Upload or remove the login logo | Edit Project |
| Disable, enable, trash, restore, purge | Manage Project |
| Delete outright | Delete Project |
| Export/import the view tree | Manage Designer |
| Export/import a project backup | Manage Project (import: Create Project) |
Project resources
Everything a project contains is addressed under one namespace and served through a single resource API, which is also what LiveView loads at runtime.
| Resource | What it is |
|---|---|
| Manifest | The project's declared structure: views, routes, exports, settings. |
| Views | One resource per screen, addressed by slug. |
| Scripts | Client scripts (browser) and Gateway scripts (server-side Python entry points). |
| Named queries | Saved, parameterised queries with their connection baked in. |
| Access policy | Who may view the project's runtime, and how. |
| Files | Images, models, documents and other assets in the project tree. |
Resources are optimistically locked: saving a view carries the revision you loaded, and a conflicting concurrent save is rejected rather than silently overwriting. Two engineers on the same screen get a conflict to resolve, not a lost edit.
Runtime identity binding
A project may be bound to a User Database — an external identity source for its operators.
- Unbound (default): LiveView is public. Anyone who can reach the URL sees the screens.
- Bound: LiveView requires a runtime login at
/{project}/login, and runtime roles govern what each operator may see and write.
The binding is authoritative and is written only through its dedicated endpoint — never through the project manifest, so an author cannot grant themselves access by editing a resource.
A binding can outlive its User Database. Changed in 1.0.8 A project restored from another machine, or one whose User Database was deleted, can still name a database that no longer exists. The project stays login-only, but nobody can sign in, so every screen shows no data. The LiveView access field in Project Properties now shows Missing User Database (deleted) with a warning, and a sign-in attempt says the database is gone instead of reporting an unknown user. Choose another database, or None — public.
Branding New in 1.0.8
A project can carry its own logo, shown on its LiveView sign-in — the full-page login and the in-view overlay alike — in place of the QUBIQ mark. Set it in the Branding card of Project Properties (Project Settings in the Pipeline workspace); it needs Edit Project.
- Drop a file on the card, or browse. PNG, JPEG or GIF, up to 2 MB and 2048 × 2048 px. A transparent PNG at about 3:1 (600 × 200, say) sits best. SVG is refused: the logo is served to visitors who have not signed in, and an SVG can carry script.
- The upload is saved at once — it does not wait for Save & Deploy. The image is re-encoded to PNG on the server.
- Once set, the card previews it inside a miniature sign-in header on a light and a dark surface, because a logo drawn for one usually vanishes on the other. Replace logo and Remove sit beneath; dropping a new file on the card replaces it too.
- If there is no logo, or the image fails to load, the login falls back to the QUBIQ mark.
The logo is stored with the project's files, so project backups, exports and a purge carry it.
Control size New in 1.0.8
Project Properties → Theme → Control size sets the default height of every input, dropdown, button, menu and tab in the project's views, in the Designer canvas and in LiveView alike. It saves with the project, with the rest of the theme settings.
| Option | Field height | For |
|---|---|---|
| XS — 28 px | 28 px | Very dense desktop dashboards |
| SM — 36 px (default) | 36 px | Desktop dashboards |
| MD — 44 px | 44 px | Touch — a 44 px target |
| LG — 52 px | 52 px | Touch panels |
| XL — 64 px | 64 px | Gloved hands, far-away displays |
A widget whose size is Project default follows it; a widget set to its own size keeps it.
Before 1.0.8 these widgets drew at what is now MD, and the default is SM, so an upgraded project's fields, buttons, menus and tabs come out one step smaller. For a touch panel, or to keep the old look, set Control size to MD.
→ One size scale · Control size in views
Backup and transfer
Two granularities:
| Scope | Contains | Use for |
|---|---|---|
| Project backup | One project's resources, assets and pipeline definitions | Moving an application between environments |
| Gateway backup | Connections, namespace, tags, bindings, alarms, UDTs, users and the project registry | Disaster recovery, machine migration |
Both can be passphrase-encrypted; only an encrypted archive carries connection secrets.