The Project Context & App Version¶
Audience: everyone.
LQMS keeps several projects (scopes) side by side, strictly separated. The top bar tells you how to get around, which project you are looking at, and which version of LQMS you are running.
0. Finding your way — the top bar's three groups¶
The navigation is grouped by when you use it, so the daily tools stay in front and the occasional ones tuck away:
- Work — the surfaces you touch every session, kept flat and prominent: Documents and your Inbox (your review tasks, obligations and acknowledgements), plus My training. A small count bubble on the Inbox shows how many items need your action right now (pending or overdue obligations, reviews awaiting your approval, trainings you have not yet acknowledged); it disappears when there is nothing to do.
- Evidence — one grouped Evidence menu for the things you produce for a reviewer, reached at review, audit or submission time: Dossiers, the Authority snapshot, Traceability, and the audit pack. Each entry carries a one-line note on what it is. In particular:
- a Dossier is a curated, structured, versioned submission you assemble and issue as a record;
- the audit pack is everything released in the project, uncurated, regenerated on demand — it appears only when a single project is in context (and you may view it), because it is inherently per-project.
- Administration — the Admin entry (users, roles, document types, project setup, scopes, activity) for installation-wide governance. It is kept separate from the per-project configuration gear beside it: Admin is installation-wide, the gear governs the one project in context. They are different jobs and stay apart.
Every entry appears only if your role can use it — and a whole group hides itself when you have nothing in it (a member with no evidence surfaces sees no Evidence menu; someone with no governance rights sees no Admin). The LQMS mark at the far left is a link back to your home view.
On a narrow screen (phone or small tablet) the whole nav folds into a single More menu so the bar never scrolls sideways; a laptop or desktop shows the groups inline.
One more thing can appear in the bar, just before the project switcher, and only for you: while you hold a role temporarily — you took it through a refusal that offered it — a chip names the role and the time left (Acting as QMB — 42 min left, or just QMB · 42 min where the bar is tighter). It turns amber in the last five minutes and carries Extend… and End now in its own menu. Nobody else sees a badge on you; what everyone else reads is the trail. See the permission I need is held by a role I do not hold.
1. One project switcher, everywhere¶
The top bar carries a single Project context switcher (the workspaces icon beside the search box). It is the app's one project filter — there is no second project selector hidden inside individual views. It offers All projects and then each project you can see, listed as its code and name.
Your choice is remembered across reloads and applies everywhere at once: pick a project and the documents list and search show only that project's items, and the traceability workspace's focused views load that project; pick All projects and the views that can show several projects show them all.
2. Views that need a single project — the "Select a project" prompt¶
Some views only make sense for one project at a time — the traceability workspace's focused sub-pages (requirement coverage, requirement chains, risk, training compliance, obligations oversight) and the traceability-report download, whose data is per-project by design.
- When the switcher names a project, that project is used directly — no extra picker appears.
- When the switcher is on All projects, such a view shows a neutral Select a project prompt (a placeholder dropdown and a short explanation) instead of data — nothing is loaded until you pick one. Its hint names the view, e.g. "Select a project to see its Obligations oversight."
Picking a project in that prompt does exactly what picking it at the top does: the toolbar switcher follows and the filter now applies everywhere. A traceability link that names a project (a shared URL) selects that project on arrival, so shared links land on the right data.
3. Where the filter deliberately stops¶
- Your inbox is never filtered. Your tasks span every project you work in, so the inbox shows all of them regardless of the switcher — on purpose.
- Pickers inside an action (choosing where a new document goes, the target of a link) select the target of that one act — they never change your project context.
Scope configuration (the gear menu) follows the context like every other view: it administers the project your switcher shows, asks you to Select a project when the switcher is on All projects, and picking there updates the switcher — the same one-selector behavior as everywhere else. If the context is a project you cannot configure, you get the picker offering only the projects you can.
4. Which version of LQMS am I running?¶
Open your user menu (your name, top right). The Build line at the bottom shows the running product version first, with the underlying build stamps (the browser bundle's and the server's) behind it — the auditor-facing number leads.
- A released build shows its version verbatim, e.g.
v0.8.0. - A build that is not a tagged release shows
unreleased(with a short build id) — so the number never claims to be a release it is not. - If the page and the server report different builds, the line flags "UI and server builds differ" — a prompt to hard-refresh, because you may be looking at a stale page.
The version is deliberately kept off exported document faces (a PDF's identity is the document, not the tool). The exporting tool version is instead recorded in the export's audit event, where it is available as evidence without stamping the controlled copy.
5. Why a fast screen shows no loading indicator¶
Most screens in LQMS load in well under half a second, and when they do you will see nothing at all between clicking and reading: no bar, no spinner, no flash of empty boxes. That is deliberate. A progress bar that appears and vanishes inside a few hundred milliseconds buys nothing — it is a second thing your eye has to process, and an interface that draws attention to waiting is remembered as slower than the same wait spent looking at content.
So a loading indicator is held back until a read has actually been running for a moment, and once it does appear it stays long enough to be read rather than strobing away. Two consequences are worth knowing, because they are what makes this honest rather than merely quiet:
- A real wait is never hidden. A genuinely slow read still gets its indicator, on time. Where the shape of the content is known in advance — the folder tree, a document's body — you get a greyed outline of the rows that are coming rather than a bare bar.
- Silence never means "empty". Inside that first moment the screen says nothing because it does not know yet; it will not tell you a folder has no documents until it has an answer. "No results" is a claim, and LQMS does not make claims it cannot yet support.
Something you triggered is different. A save, an upload, an export or any other act you just asked for gets its feedback immediately — deferring that would make the app look as if it had swallowed your click. The rule above is about reading, never about acting.
And when you move from one document straight to another, the document you were reading stays on screen until the next one arrives, rather than blinking through an empty state. Its actions are disabled while that is happening, so a click can never land on the document you are leaving.
Governing decisions: ADR-0093 (one scope context — the toolbar switcher is the only project selector, the neutral picker for views that need one project, deep-link precedence), ADR-0090 (release & versioning policy — semver product version, the auditor-facing badge, the tool version in the EXPORTED audit event). Project separation itself: ADR-0002/0007 (the switcher is a display filter; every request stays server-authorized regardless of it).