Projects module

The Projects module is a registry for OT project and source packages. It is separate from Equipment and from backup version history: a Project can be linked to several equipment items, while each equipment item can have at most one linked Project.

Projects give teams a controlled way to check out, update, and retain the package used for an OT asset without treating backup files as source files.

Settings

Configure Projects from the Projects group on the Configuration page.

Enable Projects enabled before users can access the global Projects page or Project actions in Equipment. Keep it disabled when the organisation does not use Project package management.

Keep Require comment for project check-in/out enabled to require context for every reservation and package update. Disable it only when your operating procedure records that context elsewhere.

Project Workflow

Users work with Projects from two places:

• A global Projects page for creating, viewing, editing, and managing all Projects.
• The existing Equipment dialogs for linking a Project to one equipment item at a time and for performing package actions on that equipment's linked Project.

Equipment Details shows a single Project tab only when that equipment has a linked Project. That tab offers these actions:

• Check out a Project.
• Check in an updated package.
• Cancel an active checkout.
• Download the current package.

Equipment Edit is responsible for linking, unlinking, or changing the linked Project. You cannot change the link from Equipment Details. Bulk linking is not available.

Project Versions And Packages

A Project may exist without a package. For an empty Project, the first package action is Upload initial version rather than checkout.

Each check-in or upload creates exactly one immutable Project Version:

• Versions receive automatic sequential numbers within their Project and may also have user-provided labels.
• One upload accepts one package file, using the existing resumable upload mechanism.
• The relevant adapter creates the version package. Projects store whole packages; file-level version control and comparison are not included.
• Project packages use the existing backup storage infrastructure, in a separate Projects folder. Backup operations must not overwrite them.

The storage layout is similar to {BackupStorage}\Projects\<Equipment>\<Version>. Users will not configure a filesystem path per Project.

flowchart LR
A[Create or link Project] --> B{Project has a version?}
B -- No --> C[Upload initial package]
B -- Yes --> D[Check out Project]
D --> E[Update package outside OT Backup]
E --> F[Check in one package]
C --> G[Create immutable version]
F --> G
G --> H[Store package under Projects storage]

Checkout Policy

Projects use Strict checkout. A Project must be checked out before a new package can be checked in, which prevents conflicting edits to the same Project.

Only the account that checked out a Project can check it in or cancel the checkout. Ownership uses the account's stored ID, not its displayed name: local and external accounts with matching names remain separate.

A user with the ForceClearProjectCheckout privilege can open the Project and select Forcce clear checkout. The intended owner can then check it out again and check in their saved working package. Existing Project versions are not deleted. Do not assign ownership by matching a name: different accounts can share one.

If the module is disabled after Projects are in use, OT Backup archives Projects and clears active checkouts with audit logging. Project data is not silently removed.

Scope Boundaries

Projects is a package registry, not a full source-control system. Git-backed file-level history, diffs, and comparable exported formats for opaque project types such as TIA Portal are not included.