Use permanent job IDs with editable names and archive prefixes

[TheTwist76]

Goal and approved scope

Fix the job-identity design defect on the existing main codebase. Give every
backup job one permanent unique job_id and use it wherever the application
currently uses type_id, backup_type or a type/location-derived key to identify
a job. The application should otherwise look and behave almost exactly as before.

Maintainer clarification on 2026-09-07: the job name AND archive prefix must remain
editable independently of the immutable ID. The archive-prefix field contains the
complete prefix, for example flash-backup; only the timestamp is appended.
This replaces the earlier wording in this issue that excluded editable prefixes.

Only the changes listed below are authorized. Any additional improvement,
redesign, feature or behavior change must be explained and explicitly approved
by the maintainer BEFORE implementation, even if it appears useful.

Starting point

• Start from a fresh branch of current origin/main. The reviewed baseline is
  3f4058ca4d8a9b947c46467706e4bbd0d4c31de5 (2026.09.07.0935).
• Introduce immutable job IDs across all job-dependent data and workflows #447, PR Introduce immutable job IDs and guided migration (#447) #480 and codex/issue-447-immutable-job-ids remain frozen. Do not resume,
  merge or wholesale cherry-pick their implementation. The maintainer explicitly
  approved reusing Introduce immutable job IDs across all job-dependent data and workflows #447's dependency analysis as a checklist, checked against Main.
  The existing Main migration infrastructure must be used for Use permanent job IDs with editable names and archive prefixes #486. The approved
  visual references below remain limited to the specified UI changes.
• The maintainer handles restoration of the Unraid installation to main separately.
  This issue does not request a rollback of live data or conversion of the frozen
  Introduce immutable job IDs across all job-dependent data and workflows #447 test installation. Implementation has not started; this update records the
  scope and the main-code review.

Isolated implementation and test workflow

• Implement the entire feature on one fresh branch,
  codex/issue-486-job-ids, from the reviewed current main baseline, with one
  implementation PR. Keep incremental work and corrections on this branch/PR;
  do not merge partial identity cutovers into main.
• Keep the implementation PR unmerged until the maintainer completes the agreed
  feature test. Closing the unmerged PR allows the code experiment to be discarded
  without reverting changes on main.
• Before implementation, map each affected persistent file and its ID readers and
  writers, define representative main-format test data, and make the expected
  before/after differences explicit. This is preparation for the agreed feature,
  not a separate architecture or refactoring project.
• Unraid does not provide the plugin downgrade assumed in the earlier planning.
  Closing an unmerged PR discards the source-code experiment; it does not downgrade
  an installed test plugin or undo data migration. Migration snapshots protect
  data and are not a plugin rollback. Do not promise installing an older Main
  package as the normal return path or add a rollback mechanism to Use permanent job IDs with editable names and archive prefixes #486.
• Test migration/retry on data copies first and preserve affected originals.
  Corrections to an installed test version use a corrected version and documented
  data repair where necessary. Any separate installation recovery needs its own
  concrete plan and authorization; archive operations are not undone by restoring
  configuration files.
• Publish verified test-channel candidates from this implementation branch using
  the existing preflight/deploy workflow. Each corrected candidate remains linked
  to the same implementation PR.
• A later approved stable promotion still uses the separate release PR required
  by the repository workflow; it is not another feature implementation PR.
• Introduce immutable job IDs across all job-dependent data and workflows #447 stays frozen and Scheduled restore tests do not create a cron trigger #493 remains independent.

Main dependency analysis

The existing config/jobs/*.json files are the starting records. Determine their
readers, writers and dependent references rather than replacing every occurrence
of type_id or backup_type indiscriminately.

Reader/writer analysis for #486
records the existing stores and functions, verified against Main. It reuses the
original #447/#471 inventory at 9ac8715 and checks the frozen later inventory
for additions such as activity-log capture. It does not adopt #447's new modules.

The analysis covers job metadata; .status files shared by Dashboard, backup
History and reports; weekly values; Restore Test .test files; separate restore
run/history stores; schedules; repository job references; notifications; runtime
recovery; locks/activity logs; widgets; import/export; and existing diagnostics.
It also identifies descriptive/default uses that must not become UUID values.

Use Main's run_startup_migrations(), existing audit and atomic-write helpers,
and existing startup failure handling. Add one job-ID migration to that path.
Normal readers that also write must not run against a partially converted set.

Identity and editable fields

• Generate and persist a UUID once for each job. Edits, renames, prefix changes,
  runs, restarts and updates preserve it; new/duplicated jobs receive a new ID.
• Use that ID throughout job APIs, scheduler/cron, runtime and locks, status,
  dashboard/widgets, history/reports and weekly values, notifications, repository
  references, Browse & Restore, restore tests and existing import/export flows.
• Names, archive prefixes, types and locations must no longer act as job identity
  keys. Legacy fields can remain as descriptive or operational data where needed
  to preserve existing behavior; do not blindly remove or replace every occurrence.
• Keep the existing job settings and data structures where practical. Enrich them
  and change the necessary reference keys; avoid a replacement architecture,
  broad schema cleanup or unrelated file/directory reorganization.
• Display name is editable. The former Type-ID input becomes the complete editable
  Archive prefix. Example: legacy flash used flash-backup-<timestamp>; migration
  preserves that prefix and the field shows flash-backup.
• Changing the prefix changes names of future archives only. Existing archives
  are not renamed. Preserve the main branch's existing recorded-prefix handling
  for finding older archives; the job's ID and linked history stay the same.
• archive_prefixes already exists in the released main version. It is not a
  feature introduced by Introduce immutable job IDs across all job-dependent data and workflows #447. Preserve the complete existing list, for example
  ["testdaten-backup", "testdaten_history-backup"], and its current use in
  Browse & Restore to find archives under current and previous prefixes. Prefix
  edits must continue recording prior prefixes. Introducing job IDs must not
  remove, shorten or replace this list.

Additional prefix rules approved on 2026-09-07

• The complete archive prefix does not have to end in -backup. For example,
  flash-config is valid, and future archives use flash-config-<timestamp>.
  Migration preserves the actual existing prefixes; it must not strip -backup.
• Within one repository, a prefix's archive selection must belong to only one
  job. Reject a new or changed prefix if it conflicts with a current or recorded
  previous prefix of another job in that repository.
• Check archive-selection overlap as well as identical strings. For example,
  flash-* also matches flash-config-<timestamp>, so flash and flash-config
  conflict between different jobs in the same repository.
• A job may reuse its own recorded previous prefixes. The same prefix is allowed
  in different repositories.
• Explain a rejected prefix using the existing validation/error presentation and
  identify the conflicting job. Do not silently rename jobs or archives, delete
  existing data, or discard recorded prefixes to resolve a conflict.
• These checks protect the existing prefix-based Borg behavior. They do not
  authorize a combined-retention algorithm or inserting job IDs into existing
  archive names/content.

Explicitly approved UI changes

• Adapt only Job Wizard step 1, using the corresponding Introduce immutable job IDs across all job-dependent data and workflows #447 step as the visual
  reference: clear editable job name and full archive prefix, with existing icon,
  color and other settings preserved.
• Show the read-only job ID when editing a job.
• Show the read-only job ID in the existing expanded History run details.
• Dashboard and all other areas use the ID internally while retaining readable
  labels, current grouping, counters, layout, icons and colors.
• Maintainer clarification: sort job lists and job selectors alphabetically by
  the configured job name, including Dashboard, Jobs, Browse & Restore, Restore
  Tests, and job selection/filter controls in other areas. Within existing groups
  (for example storage location), sort by job name rather than UUID, filename,
  mutable identity key, or the previous fixed backup-type ordering. Renaming a
  job updates its alphabetical position without changing its identity. Preserve
  the chronological ordering of history/report run records.
• No further page redesign, badges, counters or wizard changes are authorized.

Small migration on the existing startup path

• Reuse the central migration registry, existing audit/error reporting and startup
  failure handling. Do not introduce another migration assistant or framework.
• Record a durable old-key-to-job-ID assignment, preserve affected originals, then
  enrich existing jobs and the files/references actually needed for consistent ID
  use. A restart/retry must reuse the same allocated IDs.
• Preserve settings, unknown fields, schedules, timestamps, log references, restore
  results, check values and other existing data. Do not rewrite archive/log content
  or invent missing historical evidence.
• Convert unambiguous references. Preserve and report unresolved historical data;
  conflicting active assignments must not silently become guessed or deleted jobs.
• Keep the migration idempotent and recoverable on a failed/interrupted write.
  Use the existing migration contract and useful masked diagnostics.

Preserve existing behavior

• Keep native Borg prune and its complete verbose per-archive output. Retention
  values and main's current-prefix prune behavior remain unchanged. Existing
  prefix changes do not authorize a new combined-retention algorithm or per-prefix
  repeated pruning. Any proposed change to that behavior requires prior approval.
• Keep backup, restore, repository, runtime and scheduling behavior apart from
  their necessary transition to ID-based references.
• Keep support bundles complete to the same diagnostic scope as main, with the
  existing secret masking. Do not shorten jobs/configuration or hide useful fields.
• Preserve metadata used for automatic icons/colors and runtime defaults. The ID
  migration must not turn presentation or existing check/restore state into a
  regression or reset existing state merely because its lookup key changed.

Scheduling boundary

• Preserve backup cron expressions and enabled states in config/schedules.json
  while replacing backup-job identity references with the permanent job IDs.
• Preserve per-job Restore Test policies and their existing test results through
  ID-based references. The shared restore_test schedule is a dispatcher, not a
  backup job, and does not receive a backup-job UUID.
• The missing automatic Restore Test cron trigger is tracked separately in Scheduled restore tests do not create a cron trigger #493.
  Creating that trigger or changing its frequency/UI is outside Use permanent job IDs with editable names and archive prefixes #486.

Acceptance and focused implementation checks

• Compare representative main-format jobs and linked files before/after migration.
  Only necessary identity/reference/prefix-field changes and migration metadata may
  differ; retained job settings and historical evidence must remain equivalent.
• Rename a job and change its prefix: ID, schedule, history, dashboard assignment
  and existing restore/check data stay linked to the same job. New archives use
  the new complete prefix; existing archives remain unchanged.
• Test prefixes without -backup, rejection of duplicate/overlapping prefixes
  belonging to other jobs in the same repository (including previous prefixes),
  reuse of a job's own previous prefix, and equal prefixes in separate repositories.
• Verify each consumer uses the ID and does not recreate a type/location key as
  an alternate identity. No ghost jobs, UUID sorting or UUIDs replacing UI labels.
• Use jobs whose UUID/file order deliberately differs from their name order.
  Verify alphabetical job-name ordering in every job list/selector, preserving
  existing groups, and verify reordering after a name change. Run-record history
  and report chronology must remain unchanged.
• Verify a second migration run creates no new IDs or duplicate records, and test
  a practical failed/interrupted conversion without losing original data.
• Compare native prune output, support-bundle completeness and the unaffected UI
  against main. Test the three approved UI adjustments and job-name sorting in
  German and English.
• Follow the repository's test-channel/preflight workflow once an integrated,
  testable change is ready. Stable release requires explicit maintainer test approval.

User impact: reliable job identity across all existing workflows, editable names
and complete archive prefixes, with the existing application otherwise preserved.
Release notes are relevant and must describe only this scope and necessary
migration steps. Packaging fix #484 is already included in the reviewed main
baseline; Restore Test scheduling fix #493 remains separate.