Parts, revisions and check-out
Parts and part numbers
A part is one design: a single part, an assembly, a family or a template. Its part number is its identity everywhere: in the database, in URLs, in document keys and in the folder its documents are stored in. Part numbers are unique across the server, ignoring case.
Each part has a part type, which decides how its number is made. Administrators manage part types under Administration → Part types. Each type uses one of four numbering modes:
| Mode | The number is |
|---|---|
| Counter | a prefix and a fixed number of digits, counted up by the server (the seeded default is CPART followed by 9 digits). A typed number is refused. |
| Free text | whatever the user types |
| Pattern | a typed number that must match the administrator's regular expression in full |
| Script | decided by an administrator's script, which may accept, change or refuse a typed number |
A part also has a name, a description, a category, tags and attribute values (see
Catalog, BOMs and sourcing), and a document class set
when it is created and never changed: normal (a part or assembly), family or
template. The class matches the file extensions the CAD app uses: .nbrep, .fbrep
and .tbrep.
Revisions
A part has one or more revisions. Each revision holds one CAD document. A revision's
label is free text, unique within its part ignoring case; when nobody types one the
server suggests the next letter (A, B, … Z, AA). An administrator's
revision-label.js script can decide labels instead.
A document is addressed by its document key, part/<part number>/rev/<revision>,
for example part/CPART000000001/rev/B.
A new revision starts from the document of the part's current release, or, when nothing is released, from its newest revision. So revising a part starts from what the part currently is, never from someone else's unfinished draft. It also starts with that revision's uses list and revision attachments. By default a part may have several revisions in work at once; an administrator can limit it to one (Allow multiple open drafts in Server settings).
A draft can be deleted (by an author, and not while another user has it checked out), unless it is the part's only revision or an assembly's uses list pins it. Released history is permanent.
The lifecycle
| State | Means | Document |
|---|---|---|
| Draft | in work | writable by the user holding its check-out |
| In review | submitted for review | writable by the user holding its check-out; approvals given on an older version stop counting |
| Released | the current approved revision | immutable |
| Superseded | an earlier release, replaced by a newer one | immutable |
| Obsolete | withdrawn | immutable; final |
The moves the server allows:
| From | To | How |
|---|---|---|
| Draft | In review | Submit for review (authors). Opens a review round. |
| In review | Draft | send back for more work (authors), or a reviewer's rejection. Withdraws the round. |
| Draft or In review | Released | Release (the checkin group) |
| Released | Superseded | automatically, when a newer revision of the same part is released |
| Released or Superseded | Obsolete | withdraw the revision |
Everything else is refused: nothing leaves Obsolete, and nothing returns to Draft from Released or Superseded. There is no way to rewrite, un-release or delete a released revision; to change a released part, make a new revision.
Administrators can rename the states for display, and turn In review, Released and Obsolete off, in the setup wizard. Draft and the automatic Superseded always stay on.
What a release checks
A release is refused, with every reason named, when:
- the revision is still checked out: check it in first;
- its required catalog attribute values are missing or no longer valid;
- Require released children is on and something in its uses list is not released (with the setting off, the release goes ahead and its warnings name those children);
- its review round has not collected the approvals its rule needs, or approvals were given on an older version of the document;
- a workflow marked Require this workflow for part release applies to the part and the release is not that workflow's release step;
- a bake is still pending for it;
- the administrator's
before-release.jsscript refuses it.
After the release commits, after-release.js runs; its failure comes back as a warning
beside the successful release, since a committed release cannot be undone.
Check-out and check-in
A revision's document is written only by the user holding its check-out lock.
- Check out takes the lock on a Draft or In-review revision nobody else holds.
- Check in releases your lock. The document stays as you last saved it.
- Break lock: a member of the
checkingroup can release a lock someone else holds, for example when a colleague is away.
Saving to a revision without its lock is refused, as is writing a released revision, with a sentence naming why. In the CAD app the document stays editable in the session, and you can check out and save, or save your edits to a new revision or a new part with Save As. See Connecting the CAD app.
Superseded revisions in assemblies
An assembly names a specific revision of each part it places. When a newer revision of one of those parts is released, the one the assembly names becomes Superseded.
- A released assembly keeps the revisions it was released with. That is correct by design: it records what was built.
- An assembly still in work should usually move to the current release.
When you open an assembly in the CAD app that places a superseded or obsolete revision, the PLM pane says which, and offers to update it (see Connecting the CAD app). In the server, the BOM marks such a line ("uses superseded rev A; B is current"), and Replace everywhere can move every assembly in work to a new revision at once (see Catalog, BOMs and sourcing).