Administration & governance tools

Beyond the everyday features, TSync has a set of admin consoles that watch the health, history and safety of the system. You don't use them daily, but it's good to know they exist and what they answer.

Health & Release Readiness

/admin/tsync_health — a single dashboard that checks the system is correctly set up: are the modules in a consistent state, are the finance/accounting chains wired, are migrations applied, are there configuration gaps? It runs the same quality checks used when a release is built, but here in read-only advisory mode (warnings and info, never blocking). Open it after an upgrade, or when something feels off, to get a fast "is everything wired?" answer.

The "Release Readiness" section loads a few seconds after the rest of the page. That is deliberate: producing it runs the full set of release checks over every file, which takes far longer than everything else on the page put together. Rather than make you wait for the whole page, TSync shows you the rest immediately and fills that section in when it is ready — you will see a short "running the release gate" note with a placeholder while it works. If it cannot be produced, it says so instead of spinning forever.

Files left over from older versions

An update adds and replaces files — it never deletes. So a file retired from the product three versions ago stays on your server indefinitely. Nothing uses it any more, but it is still there.

That had an unexpected consequence: this page sometimes reported problems that do not exist in the product. It happened exactly that way — a security alert pointed at a file that had been retired three months earlier. It was searched for in the code and in the archives; it was in neither. It was only on that one server.

The section now lists the files that are on your server and were not in the delivered archive. A leftover .php file shows as a warning; anything else, as information.

TSync deletes nothing. It tells you what it found and where; you delete it on the server once you are satisfied. An upgrade that removes files on its own is precisely the kind of operation that cannot be undone.

Two things will never appear in the list, so it stays readable: the system's own working files (logs, caches, your configuration with its passwords) and separately installed modules — a module you installed yourself is not a leftover, and offering it up for deletion would be the worst mistake this could make.

External integrations — which ones still answer

The same page carries an External integrations panel: one row per integration your installation can talk to — ANAF, the Fisc, a bank, a CRM, a messaging provider — with the result of that integration's last real call, when it happened and where it went.

The page makes no outbound call of its own while you look at it. Probing every provider on each page load would be traffic caused by the act of looking, at services that limit how often you may call them; a health page must not become the problem it reports.

Three states, and the third is the point:

"Never checked" is the one to read carefully. If nobody presses the button, the absence of failures is not evidence of health — that is exactly how a search endpoint that had gone dead at every client survived unnoticed across an API change. A row that has answered but not for a long time is also marked as such.

The list is built from the integrations the product declares, not from what has been used, so an integration nobody touches still appears. Nothing about the content of a call is stored — no addresses, no request or response bodies; only a result, a short status token and the timestamps.

Security console

Configuration Center → Governance & audit → Security console (also in the Setup menu). One screen that gathers what the security mechanisms already in place are reporting: anti-scraping, active blocks, authentication, sessions, permissions, public routes, data access, agent tool calls and the latest audit entries.

It refuses nothing. The page is read-only — it does not block a user, cancel a session or stop a request. It shows you what is happening so you can decide.

Each card says plainly which of four things is true:

That last one matters more than it looks. "0 CSRF rejections" and "nobody counts CSRF rejections" look identical on a screen and mean opposite things — and the reassuring one is the false one. Two cards are honestly marked not built today: CSRF rejections and file integrity.

The overall posture counts switched off and not built separately, because the first is your decision and the second is ours.

Who sees it: administrators. For anyone else, grant Security console → View in permissions.

Portal access

Who can sign into the customer portal — one list, kept current, with the actions to fix it. In the sidebar under Customers.

Every contact appears with its customer, the economic partner behind it, and two things you cannot see from the customer screen without opening it: the state of its access and when it last signed in.

Three states, not "has access / doesn't"

• Active — the contact is active and has a password. It can really sign in.
• Blocked — it cannot sign in, whatever else is true.
• No password — it is active but has no password, so it still cannot get in.

That third state is why this screen exists. Allowing access for somebody with no password grants nothing — so when you do it, the system tells you who it did not help, and offers the button that actually fixes it: Send set-password e-mail.

The actions

Tick rows, then choose. Each one asks first and tells you how many contacts it will touch, then reports how many rows really changed.

• Block access — they cannot sign in again until you allow it.
• Allow access — with the warning above for contacts that have no password.
• Sign out now — see below.
• Send set-password e-mail — only to the selected contacts that have no password.
• Remove the password — the contact stays, with all its history; it simply cannot sign in until a new password is set.

"Block" and "sign out" are not the same thing

Blocking stops the next sign-in. Somebody already signed in stays in until their session expires. Sign out now ends the sessions open at this moment.

If you need somebody out immediately, use both.

On some installations sessions are stored in a way this screen cannot reach. It will say so plainly rather than claim to have signed anybody out — blocking still works.

Who sees it

Anybody with the customers permission: viewing shows the list, editing enables the actions. There is no new permission to configure.

Everything any of these actions does is written to the audit log, with who did it and to how many contacts.

Audit log

/admin/tsync_audit — an append-only record of important changes: who changed a setting, who posted or reversed an accounting entry, who ran a repair, and so on, with the old and new values. It is the place to answer "who changed this, and when?". Entries are never edited or deleted.

Design Governance

/admin/tsync_design_governance — keeps the interface consistent. It measures UI "drift" against an accepted baseline (stray inline styles, off-scale spacing, raw colours instead of brand tokens), shows it per file, and lets an admin set a new baseline once cleanup is done. It's a maintenance tool for keeping the look uniform — it doesn't affect your data.

Agent Security (foundation)

/admin/tsync_agent_security — the groundwork for safe automation/AI. It holds a read-only policy, a deny-by-default tool gateway (any automated action is logged and must be allowed), and a rule that all external content — web pages, e-mails, uploaded files, bank statements — is treated as untrusted data, never as instructions. It is inert by default (no automated actions run); it's there so that when automation is enabled, it is governed from day one. See also the Intelligence Layer.

Operational data quality

/admin/tsync_data_quality — what the product knows about the state of your own data: payment modes with no financial account behind them, a metric that has stopped being refreshed, records that contradict each other. Each finding carries a severity — critical, warning or information — and belongs to one of four components: Data integrity (DIS), Operational consistency (OCS), Source reliability (SRI) and Missing data (MDI).

The page is in your language now, severity included. Until v11.2.1 the severity was printed raw, in English, inside the coloured pill you read at a glance — which is exactly where there is no time to translate anything. The component names lead with the name and keep the abbreviation in brackets, because an acronym tells something only to a reader who already knows.

A finding here is often the cause of a symptom you are chasing somewhere else. "Payment modes without a financial account" is, for example, why payments do not move treasury.

Event Inspector

/admin/tsync_event_inspector — the log of cross-module events: what was raised, when, with what payload, and which listeners answered. Use it when an automation did not run and you need to know whether the event ever happened.

Replaying an event now asks for a real confirmation and is a POST. Replay re-raises the event on the bus and runs every listener attached to it — it can create records, send messages and post entries. Until v11.2.0 it was an ordinary link, so any page an administrator happened to open could trigger a replay with their session, without a click and with nothing shown on screen. The confirmation now says what will happen rather than asking whether you are sure.

Failed jobs queue

/admin/tsync_dead_jobs — the background jobs that gave up after their last retry. This is the page you open when something stopped happening in the background.

Two actions, and their confirmations now tell you what each does: re-queue ("they will be queued again and run on the next cron pass") and delete permanently ("they will be deleted for good; this cannot be undone"). The count reads failed jobs: 1 rather than a sentence with a plural that only works in English.

These consoles are in your language

Module Health, the Event Inspector, Operational data quality, Agent Security and the failed-jobs queue were shipped in English inside a product that is otherwise used in Romanian and Russian. They are translated now, including their status words: green / amber / red used to render raw, so the page expected an operator to know that "amber" meant "needs attention" — as a colour name, in English, among otherwise translated labels.

These consoles are for owners/administrators. Who can open each one is controlled by permissions; in hub mode they're reached from the Configuration Center.