EasyPDM v0.4

This release is about what happens after a part leaves your desk: the round trip with the client.

Client verification keeps the record of that conversation where the work is, instead of in somebody's mailbox. Pick a released Part or Assembly and log what came back — verified, needs work, or simply "sent, still waiting" — with a comment and the proof attached, for example the confirming e-mail. Entries stack up, so a round of remarks followed by an acceptance stays readable as history. The project panel adds an overview split by result, answering "what is still with the client?" at a glance, and the author of an item now gets a notification when a verdict arrives.

Verification is kept per project, not per part. The same component used for two customers is accepted by two different people, so each project keeps its own record — and each entry remembers which revision it covered, so an old acceptance can never quietly stand in for a part that has changed since.

The commercial side of a project got its own place too: a quote and an order confirmation each have a dedicated slot, next to an open category for everything else that arrives with a job, and a project can now name the client contact leading it.

Among the fixes, three are worth calling out: FreeCAD assemblies no longer reach the PDM pointing at their components' pre-upload filenames (which produced a wall of "Link broken" on download), deleting an assembly no longer deletes the components it merely used, and updating a Windows installation no longer asks for the PostgreSQL superuser password or resets the database role's password.

---

Added

• Client verification for released Parts/Assemblies. With a released item selected, a
  "Client verification" button in the toolbar opens a window holding the running record of
  what the client said: each entry has a result (Verified / Needs work), an optional
  comment and its own attachments (e.g. the confirmation e-mail). Entries accumulate — a
  round of remarks followed by an acceptance stays visible as history, with who added it
  and when. The latest result also shows as a marker next to the item in the project tree
  and as a section in its properties panel. Verification belongs to the pair (item,
  project), not to the item alone: the same Part used in two projects is accepted by two
  different clients, so each project keeps its own record and none of it shows up in
  "Whole database", where there is no project context. Each entry remembers the revision
  it applied to, so after a new revision is released the old acceptance stays visible but
  is clearly marked as no longer covering what the item is now.
• The project panel now carries a client verification overview: three tables, one per
  result — needs work first (that is what requires action), then in progress, then verified.
  Each row names the item, the revision the entry covered and when it was made, with an
  arrow that jumps straight to that item in the structure. Until now the only view of
  verification was per item, so answering "what is still with the client?" on a project of
  any size meant clicking through parts one by one.
• Client verification now raises notifications: one when the client comes back with
  remarks, another when they accept. They go to the item's author — verification only
  applies to released items, and a released item never has an owner, so the author is the
  only person the system can point at. Each type can be switched off separately in Settings,
  and an entry with no result picked ("in progress") deliberately stays silent: it records
  that something went out, not that anyone needs to act.
• Order documents on a project: a quote and an order confirmation each get their own
  highlighted slot in the project panel — the same shape as the CAD file slots on an item
  — plus a third, open category for everything else that arrives with a job
  (correspondence, the client's specifications, meeting notes). Both highlighted roles
  accept several files rather than replacing the previous one: a quote gets revised and
  re-sent, and the earlier version is worth keeping. Unlike "Whole database", which is
  deliberately open to every logged-in user, these are commercial terms — so both reading
  and uploading require access to the project itself.
• Each project attachment now shows when it was uploaded and by whom, under the file name.
  Nothing forces attachment names to be unique — and rightly so, since a revised quote is
  usually named exactly like the one before it — so two entries could look identical with
  no way to tell which was which.
• A project can now have a "Project lead" — a contact picked from the client's own contact
  list (either a contact belonging to the client directly, or one belonging to the
  specific Name 2 the project is linked to), shown right in the project's properties panel
  next to Client/Name 2.

Changed

• The "Close project" button moved from the project's properties into the toolbar above the
  tree, next to the other project actions. It also stopped sending the whole project on
  every toggle — closing now touches that one flag through its own endpoint, so clicking it
  right after editing a field can no longer race that field's own save and quietly undo it.
• Updating an existing Windows installation no longer asks for the postgres superuser
  password, and no longer changes the pdm_user role's password. The installer reads the
  existing password out of the previous installation's appsettings.Production.json and
  leaves the role and database untouched — so anything else connecting to that database
  (backup scripts, pgAdmin with a saved password) keeps working across updates, and an
  update is now just "next, next" with no credentials to hunt down.
• The Windows installer refuses to install an older version over a newer one, explaining
  why instead of failing obscurely afterwards: database migrations only ever move forward,
  so an older build cannot read a schema that has already been migrated.

Fixed

• "Delete completely" on an Assembly deleted its components along with it. A Part/Assembly
  is a first-class catalog entry (own number, revisions, history, attachments) that can be
  used in any other assembly, so deleting one assembly it happened to sit in must not take
  it down. Deletion now recurses only through Folders (a Folder owns its contents; an
  Assembly only uses its components), so removing an assembly deletes just that record
  and leaves every component in place, losing only that one BOM relation.
• The FreeCAD upload macro sent assemblies to the PDM still pointing at their components'
  pre-upload filenames, so downloading such an assembly again produced a wall of "Link
  broken". Three separate causes, all found from a live Report View log:
  • The copy into the PDM ran before the local Save As under the PDM name, so the file
    that reached the server was always the pre-rename one. The order is now reversed — the
    document is renamed (and every link pointing at it refreshed) first, and only the
    finished file is copied/uploaded.
  • A component opened only as a link dependency is loaded partially by FreeCAD, and a
    partially loaded document silently refuses to save ("Partial loaded document ...
    cannot be saved"), so the renamed file never actually appeared on disk. Such documents
    are now pulled in fully before saving, and a save that produces no file is reported
    instead of being counted as a success.
  • Links to an App::VarSet (shared parameters, which two documents often point at in
    both directions) were treated as assembly components — that fabricated a cycle in the
    BOM, which the backend then rightly rejected, and inflated component quantities. The
    tree walk now skips them.
• The project's Nazwa/Opis/date fields saved on every blur regardless of whether they'd
  actually changed, which could race a genuinely intended change made right after (e.g.
  picking a Project lead immediately after clicking away from another field) and silently
  revert it if the stale, unrelated save happened to finish second.
• A Part/Assembly shared as a component under an item in a different project (via "Add
  existing item") showed up in that project's tree as a leaf, with its own
  already-existing sub-components missing — GET /api/projects/{id}/relations filtered
  relations by the parent's project_id, which excluded the shared component's own
  children (their parent is the shared component itself, filed under its original
  project). Now walks the structure recursively from the project's own items, the same
  pattern already used for a single item's BOM.