Renaming a project, and what can never change¶
Audience: whoever administers the installation — the person who created the projects, and the one who has to fix a name somebody typed wrong at birth.
Admin → Scopes is the installation's project directory: every project this installation knows, grouped under the organization it belongs to, with what each one may do. It is also the only place two things about an existing project can be changed — its name and its derive-source setting — and the place that makes visible why the third thing you might want to change cannot be.
1. How the directory is laid out¶
The table is grouped by organization, because that is the shape the data actually has: an organization is the hard separation boundary, and a project always belongs to exactly one (the birth path). Each section is headed by the organization's name, and under it stand its scopes.
The first row under a heading is usually not a project: it is the organization's own scope, the one every organization is born with, typed Organization level. It exists so that things which belong to the organization as a whole — staffing somebody into the whole tenant, the audit trail of an invitation — have somewhere to be anchored. It carries no documents of its own. Reading it as a strange project beside the real ones is the misreading this grouping exists to prevent: it is the heading's own scope, which is why it stands first and why its type says so.
Installation-wide is a section of its own, at the top, and it holds the one scope that belongs to no organization: the installation's base scope (§5). Its heading says exactly that — belongs to no organization — rather than filing it under some tenant it has nothing to do with.
There is no organization column: the heading of the section you are reading in is the organization, so repeating it in every row would only be noise.
The heading also carries what is true about the organization itself, where anything is: an organization that was founded and then left standing — no project, nobody in it — says so, with the ways out; and while an organization is still completely empty, the heading offers Dissolve organization…, the one destructive act on this page. Both are the far end of the founding process rather than of this one, so the reasoning lives with it: how a new organization and project are born, §6.
2. The two identifiers, and why only one of them moves¶
Every project carries two identifiers, and they are not the same kind of thing at all.
- The code —
QMS-OPS,CARDIO— is identity. It is the prefix every document id in the project was minted with, soQMS-OPS-SOP-001contains it, and it is also the scope half of the qualified form (doc:SCOPE-CODE/DOCUMENT-ID) that cross-project links, the document list's paging cursor and the audit-pack manifests are written in. Those ids are already printed in released PDFs, cited from other documents, sent to auditors, and stored in rows that must never be rewritten. Changing the code would therefore not be an edit; it would be a re-identification of the whole corpus. - The name — QMS Operations — is a label. Nothing derives from it, nothing embeds it, no identifier is minted from it. Every screen that shows it reads it live.
So the table shows the code in a fixed-width font with a lock, and the name with a pencil. There is no "change code" affordance anywhere in LQMS, and its absence is not an omission waiting to be filled: it is an act with no correct implementation. Getting the code right at birth is why the setup wizard checks it for uniqueness and explains it on the form (see provisioning: the birth path §2).
If a code is genuinely wrong — the customer was renamed, the project was created under the wrong organization — the answer is a new project and a documented migration of its content, not a rename: a deliberate, auditable act, which is what re-identifying a corpus should be.
3. Renaming a project¶
Hover the row, click the pencil, type, Save. That is the whole flow.
- Save stays disabled for a blank name and for the name the project already has — an empty form is not a rename, and re-saving the same name would change nothing.
- The name may be up to 200 characters. Longer, and the server refuses with a message that says so; refusals are shown to you verbatim rather than translated into "something went wrong".
- Names need not be unique. Two projects belonging to different customers may legitimately both be called Quality Management. The code is what must be unique, and it is.
- The row shows the value the server stored, not what you typed: leading and trailing spaces are trimmed away.
The change is visible immediately everywhere the project is named — the toolbar project switcher, the configuration surface, every picker — without a reload.
It is recorded. A rename writes an audit event (SCOPE_RENAMED) carrying the old name, the new name
and the project's unchanged code, attributed to you. Renaming the project back to what it was is a
second, equally recorded, event. Re-saving the name it already has records nothing at all — a change
that changes nothing is not a change. You can read all of it on
the activity trail.
4. The derive-source setting¶
The one capability that can be changed after birth: whether documents released in this project can be adopted — derived — into other projects. Off for a normal project; on for the operating organization's own base-procedure project, the one everybody else adopts from.
The same toggle lives on the project's own configuration page (the gear → Project settings), and it means exactly the same thing in both places. The safety property worth knowing, stated on both surfaces: the setting is checked at the moment somebody derives, so it only ever decides the next derive. Switching it off leaves every copy already derived in place and fully usable, and switching it back on needs no repair step.
The other ADR-0002 capability — whether a project holds its own records — is not shown here. The server sets it from the project type at birth and no surface offers it as a choice, because no genuine records-free project has appeared (see the birth path §2).
5. The base scope is not a project¶
The one scope under Installation-wide is not a project at all: the installation's base scope
(code GLOBAL). It belongs to the installation bootstrap, it holds the shared catalogue every project
draws from, and it is the derive source every project adopts from. It belongs to no organization — which
is why it has a section of its own rather than a row among somebody's projects. It offers neither
control — no pencil, no toggle — and says why instead of showing a control that would be refused.
That is a house rule, not a quirk of this page: an affordance the server would refuse is never shown as a disabled control that leaves you guessing whether you did it wrong. Either it is offered, or the reason it is not is stated.
6. Who may do this¶
Both edits need the installation-shaping permission (MANAGE_SCOPES) held at the base scope —
the same permission the setup wizard's provisioning steps need, and the same one the server checks on
every write. Holding it inside a single project is deliberately not enough: these are
installation-wide acts, recorded against the installation's own trail.
Without it, the page still reads, grouped the same way: you see the projects you may see, under their organizations, with their capabilities — that is ordinary directory information you already see in the toolbar switcher — with no controls and one line saying that changing this needs rights you do not hold here. The Scopes entry itself only appears in the admin sub-navigation for someone who holds the permission.
As always, the screen only reflects what you may do; the server decides. A request made without the permission is refused whatever the screen shows.
Governing decisions: ADR-0097 (the governed provisioning surface — the rename and the settings write, their permission and their audit anchor), ADR-0051 (scope-qualified document references — why the code is identity), ADR-0002 (the scope capability model: derive source, records), ADR-0012 (permissions are enforced server-side; the UI reflects), ADR-0007 (never show an affordance the server refuses).