OpenClockwork v2.0.0

OpenClockwork v2.0.0

OpenClockwork 2.0 introduces two explicit ways to run the same application:
Solo for one person's work and customer time, and Team for established
employee, schedule, leave and approval workflows. This is a product-generation
major release, not a replacement of the existing Team application.

Existing 1.4.0 installations can upgrade directly: their data and identities are
retained, they stay in Team mode, and no Solo owner is invented. The new Solo
contracts and deliberately stricter maintenance tools are described below;
existing Team requests are not universally required to adopt Solo-only fields.

Highlights

• A focused Solo workspace with authenticated owner setup, personal overview,
  timer, time history, calendar, customers, projects, reports and settings.
• One shared timer across browser sessions, atomic project switching, manual
  entries, corrections with reasons, cancellation and auditable history.
• Stable automatic break deduction across a capture group: splitting work or
  changing project does not restart the break threshold or deduct the same
  break twice. Calculations retain sub-minute precision.
• Customer and internal project allocation, service orders, billable time,
  filtered gross/break/net reports, CSV and printable customer statements.
• Optional, effective-dated personal targets, leave accounts and carry-over,
  holiday dates, break rules, daily target blocks, GPS and frame/core-time hints.
• Stronger session validation, protected last-administrator changes and
  conflict-aware updates, while preserving the existing Team data model's history.
• Separate public guides for
  choosing an operating mode,
  Solo mode
  and Team mode.

Solo and Team workflows

A personal workspace without fabricated HR processes

• A fresh Solo installation has one active owner. New Solo targets, leave
  accounting, break deductions, daily blocks, GPS and personal hints start
  disabled; enable only the rules you intend to use. Owner setup does not
  require an employee-management matrix or a manager approval workflow.
• Start, switch and stop the personal timer, or enter a completed interval
  manually. Future completed work and overlapping effective intervals are
  rejected. Corrections require a reason; cancellation retains the record and
  its history while removing its effect on totals.
• Personal days support free time, vacation, sickness and training, including
  half-day boundaries, editing, cancellation and history. These are direct
  personal records rather than requests sent to an imaginary approver.
• The interface supports English and German, light/dark themes, responsive
  layouts, keyboard-accessible confirmation dialogs and explicit pending/error
  states. Customer statements have a dedicated print layout, usable with the
  browser's print or Save as PDF function.

Deliberate mode transitions

• Team retains employee administration, work schedules, leave requests,
  approvals, accounts and terminal workflows. Upgrade alone does not disable
  them or convert past Team entries into Solo entries.
• Administrators preview a mode change before applying it. Open timers block
  switching; entry into Solo also requires resolving other active employees,
  pending requests/time approvals and active terminals.
• Transitions preserve identities and records. Eligible active projects are
  assigned to the Solo owner without requiring a separate assignment step.
  Switch to Team before adding another active employee.
• Access mode changes immediately. If the current working-timezone day already
  contains effective work or time off, the accounting-mode change starts on
  the following calendar day. Its effective date is recorded so switching
  access mode does not rewrite that day's targets or leave treatment.
• Solo restrictions are enforced by the API, not merely hidden navigation:
  Team/HR routes and another person's private data do not become available by
  guessing a URL.

Personal rules, precision and historical accounting

• Personal policies are versioned by effective date. Past policy changes are
  rejected, and a day with recorded accounting activity is protected against
  replacement by a new same-day policy. Future versions remain visible in
  settings. Existing time entries retain their captured break rules.
• A weekly target is distributed over the configured working days. Work from
  periods before target activation, or after its deactivation, is not silently
  turned into overtime. Historical mode and policy versions determine which
  work and targets belong in the account.
• Leave supports an annual base, explicit carry-over, optional carry-over
  expiry, and reasoned positive or negative adjustments tied to an allowance
  year. Only unused carry-over expires; consumed carry-over is not deducted
  again, and year-specific carry/adjustments do not recur in the next year.
• Personal summaries account for half days, year boundaries and inherited
  approved Team leave/absence history without double-counting overlapping
  sources. Enabling an account does not apply today's rules indiscriminately
  to earlier personal days.
• Core-time and frame checks are personal hints, not approval requirements.
  They evaluate completed past days, omit open/current-day work and avoid
  inventing missing attendance on empty or excused days.
• Capture groups use actual elapsed time. Their total automatic break is
  shared proportionally across segments, including repeated splits and
  project changes. Legacy ungrouped Team entries retain their existing
  calculation behavior. Rounding is a presentation concern, so the sum of
  rounded display rows can differ slightly from a separately rounded total.
• Reports clip intervals at local day and period boundaries using UTC
  instants. The entry form rejects nonexistent local times and requires an
  explicit UTC-offset choice for ambiguous repeated times around daylight
  saving changes.

Customers, billable work and private exports

• Customers can be linked to projects; internal work does not require a
  customer. Projects have a default billable flag, service orders can override
  it, and the selected billable value is recorded on each time entry.
• New Solo projects are assigned to their owner transactionally. Where a
  project has active service orders, a booking must select an active order.
  Archived customers/projects remain available in history but cannot receive
  new bookings; archiving a running timer's target is blocked. A booked
  project's customer cannot be silently reassigned.
• GET /api/reports/solo and GET /api/reports/solo.csv are owner-scoped and
  filter by period, customer, project, service order, billable status or
  unassigned work. They distinguish gross interval time, allocated breaks,
  net working time and billable net time.
• Open timers, rejected entries and cancelled/voided work are excluded from
  final totals. Filtering a segment does not recalculate its capture group's
  break threshold from only the visible subset.
• Customer reports include customer-facing activities but omit internal
  notes and location details. CSV exports use UTF-8 with a BOM, quoted
  semicolon-delimited fields, timezone/period metadata and protection against
  spreadsheet-formula interpretation of dangerous text prefixes. Print
  layout omits navigation, filters and internal administrative controls.
• The billable flag classifies time only: it does not set a price, calculate
  tax, create an invoice or establish a payment claim.

Authentication, concurrency and API compatibility

• HTTP authentication and token refresh check the employee's current active
  state, role and session version instead of relying on a stale role claim.
  Password changes and administrative/recovery resets invalidate earlier
  access and refresh tokens. Legacy tokens without a version are treated as
  version zero and stop working after the employee's session version changes.
• Realtime connections reject refresh tokens, enforce access-token expiry and
  check current employee/session/owner eligibility. Authorization is checked
  again before broadcasts; invalid sessions are disconnected and Solo events
  do not expose another employee's activity. HTTP remains the source of truth.
• Concurrent administrator changes cannot demote or deactivate the last active
  administrator. Solo employee-management restrictions also apply inside
  write transactions, not only at the controller boundary.
• Updates to existing Solo time entries, timer switches/stops, personal days
  and installation settings use revision checks. Stopping a Solo timer also
  identifies the open entry; Solo range allocation supplies the affected
  entry IDs/revisions. Stale state returns a conflict instead of overwriting
  a newer change. Clients should reload and ask the user to retry deliberately.
• Solo-only requirements do not make those fields mandatory for every legacy
  Team operation. Integrators should use the regenerated
  OpenAPI contract,
  handle authentication/conflict failures, and reauthenticate after password
  changes rather than retrying a revoked session.
• Initial-owner bootstrap works only with an empty employee table. A separate
  trusted-operator recovery command resets the existing active Solo owner's
  password without replacing their identity or history; it is not a general
  account-creation or mode-bypass mechanism.

Database migrations from 1.4.0

All five forward migrations run through normal prisma migrate deploy:

Migration	Purpose
20260908120000_solo_mode	Adds operating mode, installation settings/events, personal policy/day records, customers and time-entry audit history; adds project/customer and billable defaults, service-order inheritance, time-entry revision/void/capture-group/approval-mode fields, foreign keys and overlap/open-timer constraints. Existing installations receive a Team setting, not a Solo owner.
20260908130000_solo_session_version	Adds Employee.authVersion with default zero for session invalidation.
20260908140000_solo_leave_versions	Adds explicit carry-over, expiry, adjustment/reason and allowance-year fields to personal policy versions.
20260908150000_solo_personal_windows	Adds personal frame/core-time configuration and database validation of its stored shape.
20260908160000_solo_required_target	Requires a non-null, positive, bounded weekly target whenever the personal target feature is enabled.

Existing employees, times, leave records and identifiers are retained. Historical
time entries receive neutral Solo metadata: non-billable, revision zero, no void
timestamp, no capture group and no Solo approval-mode classification. The new
migrations do not replace their existing 1.4.0 break snapshots or calendars.
No intermediate 1.5.0 release or demo reseed is required.

Deployment, upgrade and rollback

• Read the upgrade guide
  before applying 2.0.0. Keep the current database/attachment volume identities,
  credentials and explicit working TZ; do not apply UTC merely because it
  is the default for a new installation.
• Pause writers and take a consistent database/attachment backup before the
  first upgraded API starts. Use unique timestamped destinations outside the
  checkout and Docker storage, protect configuration/secrets, encrypt backups,
  keep an off-machine copy, and test restoration into a separate empty target.
• Deploy matching API and web images, API first when deploying separately;
  wait for /api/health to report 2.0.0. Existing PWA/browser tabs may need
  reopening after an update. Normal production startup migrates, never seeds
  or resets, but an image change can therefore trigger a schema migration.
• Do not run docker compose down -v, volume-pruning/removal commands, Prisma
  resets or demo seeds against production. Named volumes alone are not a
  backup or a deletion lock; external volumes protect against Compose-managed
  deletion, not a Docker administrator or loss of the host.
• A new production Solo installation should have its own project, credentials,
  network and persistent volumes, with no published database port. Existing
  development or acceptance data must not be erased to manufacture an empty
  installation. Production backup scheduling, encryption, off-machine storage
  and recovery policy remain operator responsibilities.
• Forward migrations are not automatically reversible. This release does not
  declare a migrated 2.0.0 database safe to run with 1.4.0 binaries. For a full
  rollback, stop writers and restore the matching pre-upgrade database,
  attachments and configuration to an isolated recovery target before a
  deliberate cutover; retain the failed state for investigation.

Deliberately stricter maintenance tools

Development/test/demo commands now require explicit non-production targets and
operation-specific opt-ins. E2E runs must identify a matching test database
explicitly; seed/reset commands reject production execution and unclassified
database names. Existing scripts that relied on a generic database name or
inherited production DATABASE_URL need updating rather than weakening the
guard. In particular, a demo-reset job running with NODE_ENV=production is
not a supported exception. These are intentional maintenance-tool compatibility
changes, not a new requirement for ordinary Team HTTP requests.

Development Compose no longer seeds automatically and starts with demo mode
disabled. The Azure template can select a separate classified demo database
and run its explicitly enabled maintenance job in a non-production runtime;
the API remains in production mode. Existing databases are not renamed.

See the exact configuration and migration steps in the
maintenance section of the upgrade guide.
The guards provide defense in depth; they do not make a privileged database
credential or destructive Docker command safe to share with a development shell.

Validation and known limits

Validation covers automated domain/API/UI regressions plus separate Docker
upgrade/restore and representative browser workflows, including grouped break
deduction, cross-tab timers, revisions, policy history, leave expiry, timezone
boundaries and customer report output. Print-to-PDF output was also checked.
This is not a claim that every device/browser, operational recovery procedure
or long-running production scenario has received a universal manual sign-off.

• CAUR agent-usage accounting, automated model/token/runtime collection,
  invoice creation, prices, tax calculations and combined human/agent billing
  remain outside this release.
• Solo is one owner in one installation, not multi-tenant SaaS or a customer
  self-service portal. Team remains the mode for multiple active employees.
• One deployment working timezone governs day and policy boundaries; there
  are no independent per-employee working timezones. Changing display language
  does not change the working calendar or timezone.
• Maintained holiday presets cover German states. Other calendars can use
  explicit custom dates, supplied for each applicable year. There is no claim
  of automatic worldwide employment-law or accounting compliance.
• Optional targets, breaks and hints are configurable behavior, not legal
  advice. Current-day core hints are intentionally deferred, and the overview
  account cards show the current year through today rather than an arbitrary
  historical/future account-date selector.
• CSV/PDF output is a time statement, not an invoice. Browser printing/download
  behavior and access to local attachments still depend on the deployed
  environment. No automatic off-site backup or zero-data-loss guarantee is
  enabled by choosing Solo mode.

Docker images

• ghcr.io/patrickschiller/openclockwork-api:2.0.0
• ghcr.io/patrickschiller/openclockwork-web:2.0.0

Pin a release version or verified image digest; do not use latest or a mutable
development image tag for unattended production upgrades.

What's Changed

Other changes

• Release 2.0.0: Solo and Team workflows by @patrickschiller in #32

Full Changelog: v1.4.0...v2.0.0