---
title: Module management & repair
description: See, activate, upgrade and uninstall TSync modules from the Module Management Center — and recover a module whose state fell out of sync with the Module Repair Center.
product: TSync Intelligence 11.3.6
language: en
canonical: https://docs.tsync.pro/module-management/
source: https://docs.tsync.pro/llms.txt
---

# 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](admin-governance-tools.md). The
repair only ever **recovers a real prior install** — it never silently activates something fresh.