Analysts Leaving

When an analyst leaves

New in 3.7.0 · from #178 · System → Analysts

When somebody leaves, press the bin icon on their row in System → Analysts. It opens When someone leaves, which shows what they hold, offers to hand their open work to someone else, and then gives you three choices.

---

The three choices

Choice	What happens	Undo?
Deactivate	They can no longer sign in, and their API keys stop working. Their name stays on every ticket, note, change and audit entry they touched. The right choice for almost every leaver.	Yes - tick Active again
Anonymise	Everything Deactivate does, then their name and contact details are removed. Their records all stay, credited to "Former analyst #42"; their personal settings and sign-in links are deleted. For a request to be forgotten.	No
Delete	Removes the account and their personal settings. Only possible when their name is on no history at all - an account made by mistake, or a test login.	No

Why most people are deactivated, not deleted

A service desk's records are a history of who did what. If Max closed a ticket in February and left in March, the ticket should still say Closed by Max - next week, next year, and when somebody asks who approved a change. Deleting Max would either leave holes in that history or be refused by the database, so FreeITSM keeps the record whole and simply stops Max signing in.

Deactivating changes nothing about where their name appears. Nothing is renamed when they leave, and there is no grace period to set.

Their open work

Open tickets, problems, changes and tasks assigned to them - and the knowledge articles, projects, contracts and domains they own - are listed with a count each. Tick Move it to, choose an analyst (or Nobody, to leave it unassigned), and it is moved as part of the same step.

• Each item moves exactly as if you had reassigned it by hand, so its own history records the change, and the new owner is told the way they normally would be.
• Closed items keep their name. Who handled a closed ticket is history, not work.
• If an item cannot be moved - a members-only project you are not a member of, for example - the window says which, so you can open it and reassign it yourself. The rest still move.

Also set up for them

Some things are routed to a person rather than assigned to them: a form that sends its approvals to them, an SLA alert that notifies them, a seat on the CAB of an open change, rota shifts from today on, equipment still assigned to them, folders and report packs they own. These are listed, never changed for you - clearing a form's approver could let requests through unchecked, so it needs a person to decide who approves instead.

They also stop Delete: an account that is still set up somewhere is not one to remove.

Anonymise, and GDPR

Analysts are people, so their name, email address and phone number are personal data. An organisation can usually keep what it needs to show who did what, but not more than it needs, and not for longer. Anonymise is the tool for when the answer becomes "not the name either":

• the account becomes Former analyst #42, with a username and email nobody can use, and a password nobody knows;
• their job title, department, phone numbers, MFA and sign-in links are removed;
• their personal settings go: dashboards, preferences, saved views, signatures, memberships and grants;
• names FreeITSM stored beside their account are replaced too - on checklists, in the Files audit, and in ticket, task, problem and change history where an assignment recorded the name. Only a value that is their name is changed, never one that merely contains it.

What it cannot do: change a name somebody typed into the text of a note, a reply or an email. The window says so before you confirm.

FreeITSM gives you the tools; whether and when to use them is your organisation's call.

Why deleting used to fail (#178)

Before 3.7.0, Delete removed the account row and nothing else. On a fresh install, where the database protects its links between tables, that was refused the moment the analyst had a single dashboard widget saved, and the raw database error was shown:

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row:
a foreign key constraint fails (`analyst_ticket_dashboard_widgets`, CONSTRAINT `fk_atdw_analyst` ...)

The widgets were only the first of many: 212 columns across FreeITSM refer to an analyst. Removing the database's protection (the reporter's first suggestion) would have let a deleted analyst leave tickets pointing at nobody. So instead every one of those columns has been sorted into what leaving should do to it - removed with them, moved to someone else, listed for a person to decide, or kept as history - and Delete now removes their personal settings with them, and explains in words when it cannot go ahead.

For developers

The rules live in includes/analyst_lifecycle.php. The screen (system/analysts/index.php) and the endpoints (api/tickets/analyst_leaving.php, and the older delete_analyst.php) only adapt them.

Kind	Meaning	Delete / Anonymise
personal	their settings, memberships and grants (dashboards, preferences, team and module membership, folder grants - including polymorphic principal_type = 'analyst' rows)	removed
secret	sign-in material (SSO links, trusted devices, reset tokens, API keys)	removed
live	open work - moved by analystReassignLive() through each module's service	moved first; closed rows of the same columns are history
setup	routed to them; a person decides	listed; blocks Delete
history	who did what	kept; blocks Delete

• analystReferenceRegistry() is the map: every column that refers to an analyst, with its kind (and, for a polymorphic or partly-live column, the condition).
• TRAP: every column that refers to an analyst must be in the map. tests/analyst-lifecycle.php discovers them three ways - foreign keys to analysts in freeitsm.sql, person-shaped integer column names, and type + id pairs - and fails on any it does not find there. A missing one is a raw error on a fresh install's delete, or a dangling reference on an install without foreign keys.
• Reassignment goes through TicketsService::updateTicket(), ProblemsService::updateProblem(), ChangesService::updateChange(), TasksService::saveTask(), KnowledgeService::saveArticle(), ProjectsService::updateProject() and DomainsService::updateDomain() - never a bulk UPDATE - so history, notifications and workflow triggers are a manual reassign's. Contracts has no partial update or history table, so its owner is updated directly.
• Each action is written to system_logs (analyst_deactivated, analyst_anonymised, analyst_deleted) by id only: a log of an anonymisation that kept the name would undo it.

Tested by tests/analyst-lifecycle.php - see Developer Tests - System.

---

Related: Leavers could still sign in · REST API - Analysts · Bugs resolved