Module management & repair

TSync's features are delivered as modules. The Module Management Center lets you see and control them in one place, and the Module Repair Center recovers a module whose state got out of sync after an upgrade.

Module Management Center

Open Configuration Center → Module Management (/admin/tsync_module_center).

For every TSync module you see a clear version trio:

  • Installed — what is registered in the system,
  • Manifest — what the files on disk declare,
  • Stamped — what the database recorded.

When the three agree, the module is healthy. A mismatch (for example after you replaced the files but didn't run the upgrade) is flagged so you know to act. Each module also shows a health and parity status.

From here you can Activate, Deactivate, Upgrade or Uninstall a module. These are safe POST actions with a confirmation — there are no destructive one-click links.

A module's features (menus, permissions, scheduled jobs) only come alive when it is active. If a module looks installed but its menu/permissions are missing, this is the first place to check.

When an action cannot be carried out, it says so. A module that is still active, one that isn't installed, or one on the list that may not be uninstalled is now refused with the reason — previously the page answered "Module uninstalled." and nothing had happened. A success message with no effect is worse than an error: you press the button, you are told it worked, and you find out days later that the module is still there.

Upgrade DB likewise finishes instead of getting stuck. A module whose migrations could not run used to carry a permanent "DB upgrade due" badge behind a button that failed every time it was pressed; those migrations now run, so the badge clears when the work is genuinely done.

Three orange rows that were one stale record

Module Health compares what each module says about itself with what the database recorded, and it also carries a row for the platform itself. On installs upgraded through the second half of v10 and the start of v11, that platform row could read 10.6.1 on a product running v11.1.4 — fourteen versions of drift, showing up as permanent orange rows that read like three broken modules rather than one out-of-date record.

The stamp was being written by hand in each release, until one release was written without that line and every release after copied it. From v11.1.5 the platform version is derived from the migration that actually ran, so it cannot be wrong and cannot be forgotten. Upgrading corrects the row on its own — there is nothing to repair here by hand.

Module Repair Center

Open the Module Management Center and click Module Repair in its toolbar (/admin/tsync_module_repair, admin only).

This fixes a specific situation: a TSync module whose database tables already exist (it was really installed before) but is missing from the module registry — so its menus, permissions and jobs never load. The repair re-registers it as active without touching the data, so the features come back on the next load.

  • Register / Recover all stamped — bring back modules that were installed before but dropped out of the registry.
  • Sync versions — line up the recorded versions with the files on disk.

Every repair action is a confirmed POST and is written to the audit log. The repair only ever recovers a real prior install — it never silently activates something fresh.