These look alike and are not the same job.

A colleague is promoted. Their own account moves to the new address: same account, new email, everything already on it comes along. That is the Role Changes list above, and there is nothing to migrate.

A standing mailbox changes hands. president@, secretary@ and the like are accounts in their own right, with their own history. When a new person starts using one, nothing ever moved their details onto it, so it goes on describing the previous holder. That is what this tool is for.

It is not only that the name is wrong. Until this was built, president@dttasa.org still carried the previous holder's private email address, their personal mobile, their city and country, their photograph, and, in the private part of the record, their date of birth and their home address.

A departed colleague's home address and date of birth sitting on an account somebody else signs into is a data protection problem first and a cosmetic one second. Clearing it is the more important half of this job.

IT board, Role Changes, the panel headed Move a person's details onto a role mailbox.

Choose the person on the left and the mailbox on the right, then press Show me what would change. Nothing is written by that button. You get a line for every field, showing what is on the mailbox now and what it would become, grouped as identity, contact, location, signature, and what the previous holder left behind.

Everything is ticked to begin with. Untick anything you want left alone, then Apply the ticked changes and confirm. Run the preview again afterwards and it should report nothing left to change.

The account is never written: the sign-in address, the access level, every permission flag, the working pattern, the PIN and the MFA. The panel lists all of them under What this will not touch, and why, so you can see it rather than take it on trust.

This matters: a tool that could grant a permission while claiming to copy a profile would be a privilege tool wearing the wrong label. The working pattern has its own separate act, run by the Secretary General after the settling-in period.

The post is the exception, and it is deliberate rather than accidental. Part 06 explains how it is set and why it is typed rather than copied.

Almost everything moves. Who they are, how to reach them, where they work, their skills, and their service record: joining date, contract, missions, performance, training. All of it belongs to the person and follows them.

The employee number is moved, not copied. It arrives on the new account and is emptied from the old one, in a single write. A number that exists twice is not an identifier, and if the two halves could ever commit separately that is precisely what you would get.

A field the new holder has not filled in is cleared, not left. If their own record carries no phone number, the mailbox ends with no phone number rather than keeping the previous holder's. Leaving it is the exact failure this exists to fix.

The signature is not moved. It is built, not copied. Use Email Signatures on this board afterwards and it is composed fresh from the name and the post now on the mailbox. Copying the old image across would be overwritten by that builder anyway, and would be wrong in the meantime.

Somebody taking a standing mailbox is usually taking a different post, so the post is the one thing on this screen you type rather than copy. The panel shows you what the department and job title are now, next to the boxes that set the new ones. Leave a box as it is and nothing about the post changes.

What is still never written here: the sign-in address, the access level, and every permission flag. They are listed in the panel under What this will not touch, and why.

IT and super admins only, checked on the server against the portal record rather than anything the browser claims. Every run writes a system_audit_log entry naming who ran it, both accounts, which fields were copied, moved and cleared, and the post before and after. The audit records field names only, never the values: a record of somebody's home address being removed must not itself store the address.

Keep the portal trustworthy and people unblocked. IT provisions and maintains staff/volunteer accounts, runs the Help Desk, and owns the error/incident loop so failures are caught and fixed before they spread. You are the first line for anything that stops a colleague from working and the last line that confirms the portal itself is healthy.

The IT Board home opens with a Today · IT Daily Operations panel — your single "what needs doing right now" view. It shows live counts (each clickable to jump straight to that section):

A green dot means clear, amber/red means it needs attention. Beneath the counts is the Daily org-health checklist — tick each item as you do it. Completions are saved to a dated record (itDailyOps), so there is an audit trail of who reviewed org health each day and when (in WAT).

Run these at the start of the day (and glance again before you log off):

Every Diagnostics fix is universal and protective: resolve it for every future user (never a one-person patch), add a fallback where one exists, and search for the same pattern elsewhere so the whole class is fixed at once. Never hide a permission error on the client — fix the rule. Re-check Diagnostics after deploying to confirm the row is gone for the whole role.

The Today · IT Daily Operations panel on the dashboard is tagged to you — it tracks what you were assigned vs. what you did, stored per day at itShiftTasks/{uid}_{date} (a fresh list rolls over automatically each day, West Africa Time).

The task list itself is editable by SA / Head of IT via system/itDailyTaskTemplate (defaults are coded in). The headline task is always "Reviewed Diagnostics — error log & full org health."

When an error is resolved (by SA, by IT, or remotely on command), the loop is not closed until you acknowledge it with a note. On the Diagnostics page, a resolved error shows Acknowledge resolution (note required).

Every unresolved error row on the Diagnostics page has a direct Escalate to SA button (alongside the existing Head-of-IT → Exec two-stage). Use it when an issue needs the Vice President's attention directly.

The Today panel shows a live shift countdown (from your scheduled end time, WAT). When you finish, click Submit shift report. The system runs completion verification:

• The Diagnostics task counts as verified only if backed by real evidence (an escalation or a resolution acknowledgment during the shift) — or if there were no unresolved errors. Otherwise it's flagged "claimed but unverified."
• Other tasks are counted as done (self-attested).

On submit, the list locks for the day and a summary shows done/verified/missed. A PDF report (DTTASA letterhead) is generated and emailed to Head of IT + SA, and a copy is filed to the all-doc board.

To protect staff and applicant data, sensitive sections are available only during your shift. Access opens automatically 1 hour before your shift and stays open until you end it — you don't request anything.

The IT Board is the central command interface for DTTASA's IT & Digital Infrastructure department. It is accessible only to IT staff and Super Admins via portal.dttasa.org/it-board.html, and requires a re-authentication step each session for security.

Everything on the board updates in real time — no manual refresh is needed. Data is pulled live from Firestore and reflected instantly as other team members take actions.

The main dashboard displays three rows of live stat cards:

The left sidebar is divided into labelled groups: Operations, Monitor, Lifecycle, People, System, Security. Click any item to jump to that section. The board remembers your last-visited section and scroll position across sessions.

Red and amber badges on sidebar items show pending counts — prioritise items with a red badge.

When HR approves a new hire, they raise an IT Registration Request (ITR). It first goes to the Founding Executives for review and organisation-email provisioning — IT can only act once the card shows EMAIL ASSIGNED (status registration_ready). Requests still showing PENDING are waiting on the Exec, not on IT.

1. 1Find the pending ITR in the queue. Click Start Registration — this pre-fills the registration form with the applicant's details.
2. 2Verify the full name, personal email, and org email (e.g. john.doe@dttasa.org). The org email must follow the correct naming convention.
3. 3Set the department, functional role, access level (default L2 for new staff), and joining date.
4. 4A 4-digit PIN is auto-generated. You can regenerate it with the refresh button. The PIN is included in the welcome email.
5. 5Click REGISTER & SEND WELCOME EMAIL. This creates the Firebase Auth account (via an isolated secondary session — your own login is untouched), writes the user profile + private personal data + hashed security PIN, seeds the leave balance and the 90-day probation record, alerts rota managers, queues the welcome emails, and pushes a Digital ID job to Communications.
6. 6Final step — Complete. Open the person's queue card and click Complete. This verifies the account exists AND matches the exec-approved email, ticks the onboarding steps, advances the recruitment pipeline, and notifies HR. Registration alone does NOT close the request.

When the ITR record came from the HR recruitment pipeline (i.e. sourcePipelineId is set on the record), the Department and Functional Role selects are locked on the registration form — shown as disabled with a gold border and a "🔒 Locked — set by Head of HR on the recruitment request" tooltip.

This is intentional. The Head of HR set those values once, on the originating recruitment request. They flow through every downstream form so an IT staffer cannot accidentally reclassify the new starter into the wrong dept or role.

When you complete an ITR that came from the recruitment pipeline, the system stamps three new fields onto the new users/{uid} record so the offboarding sweep can later find the staff member's original applicant trail:

Symmetrically, the original recruitmentApplicants/{id} doc gets stamped back with linkedUid, convertedToStaffAt, and convertedToStaffByUid. This bidirectional link is what powers the SA "Delete User Completely" applicant-sweep and the recruitment Re-Hire warning later.

The portal's role-tier ladder is set at registration via the accessLevel field on users/{uid}:

Default at IT registration: always accessLevel: 1. Do NOT manually set isDeputyLead or any L4 flag during registration — those are managed separately by SA Control (or by the Head of the new staff member's department after registration). The Deputy promotion flow is via the makeDeputy Cloud Function, never a direct Firestore write.

Three Cloud Functions in functions/index.js manage Deputy Lead state — IT does not call these directly, but should understand them for support purposes:

Where the buttons live:

• HR Head: profile drawer of any HR-dept staff member in HR Ops Monitor → Make Deputy / Revoke Deputy.
• Other Heads: same pattern on their dept dashboards (Ops Dashboard, IT Board, Comms Board, etc.).
• SA: sa-control.html → Deputy Leads section. Lists every active Deputy across all depts + a search-and-promote form for any user.

When you sign in, the portal emails a 6-digit code to your account inbox. Enter it on the verification screen to open your portal. Even if someone learns your password, they cannot get in without access to your email — this is what keeps your account (and the organisation's data) safe.

Codes are valid for 10 minutes and work once. Five wrong attempts locks the code — use Resend code (60-second cooldown, max 3 sends per 15 minutes). Never share a code with anyone — DTTASA staff will never ask for it. If you receive a code you didn't request, your password may be compromised: change it and contact support@dttasa.org immediately.

Staff raise a password reset request when they cannot use the standard self-service reset flow (e.g. no access to their personal email). IT reviews and either approves or declines.

1. 1Go to Password Requests in the sidebar. Find the pending request.
2. 2Verify the staff member's identity if in doubt — cross-reference their profile in the Staff Directory.
3. 3Click Approve & Send Link. A Firebase password reset email is sent immediately to their registered org email.
4. 4To decline, add a note in the note field explaining the reason, then click Decline.

When you open an account, or move somebody’s sign-in during a role change, you issue a temporary password and an initial PIN. Until September 2026 only the password had to be replaced, so the PIN you typed stayed live, and the PIN is what authorises the shift seal, the personal file and the PIN-gated boards. Whoever opened the account kept a working key to it.

The first-sign-in screen now asks for both. The person cannot reach the dashboard until they have chosen their own password and their own PIN.

Check whether their sign-in was moved before you reset anything. When a role change moves somebody to a new organisation address, the old address stops signing in altogether, and Firebase answers that with the same error as a wrong password. They see “Incorrect email or password” and have no way to tell the difference.

The portal now handles this by itself, in two halves:

Staff use a 4-digit security PIN for PIN-gated pages (HR Ops Monitor, EOM, Announcement Hub). When forgotten, they raise a PIN reset request.

1. 1Go to PIN Resets in the sidebar.
2. 2Click Approve & Send Link. A secure one-time link (valid 24 hours) is emailed to the staff member's personal email.
3. 3The link opens a page where they set a new PIN. It expires after 24 hours or one use.

An account is locked after repeated failed login or PIN attempts. A lockout alert appears in the Lockout Alerts section and deducts 8 points from the Security Score per active lockout.

1. 1Contact the staff member to confirm it was them attempting to log in (not a third party).
2. 2If confirmed safe, click Resolve on the alert. The lockout is cleared and the Security Score recovers.
3. 3If suspicious, escalate to IT Head or SA before resolving.

HR can initiate a portal access block when a staff member's compliance document has expired. IT sees the pending block in Doc Access Blocks and must confirm it to activate the restriction.

Each new staff member has an onboarding checklist configured by the Super Admin. IT owns specific steps within that checklist — by default: System login created, monday.com access granted, and Uniform/equipment issued. The exact steps may vary depending on the role.

Ticking each step in the IT Board updates the staff member's onboarding progress visible to HR in real time.

1. 1Go to Onboarding IT Steps in the sidebar. Cards for all staff with pending IT steps appear here, sorted by longest wait first.
2. 2Tick each checkbox as you physically complete the step. The card shows IT-specific progress (e.g. 2/3) prominently.
3. 3If all steps are complete, click Mark All IT Complete (IT Head only) to finish all at once.

Only the IT Head can uncheck a completed step (e.g. if it was ticked in error). Click the ↩ undo button next to any completed step. An override reason is recorded in the audit log.

IT Head can add notes to a candidate's onboarding card (e.g. "Laptop not arrived yet — step deferred"). Click Add Note. Notes are saved with your name and date and displayed on the card for the team to see.

When a staff member departs, HR initiates an offboarding process through the Exec Board. Once exec-level steps are completed, IT receives a confirmation request to sign off the IT side of the departure before the case is closed.

• Firebase Auth account has been disabled or deleted
• Org email account has been closed or forwarded appropriately
• Monday.com access has been removed
• All physical equipment has been returned and logged in the Asset Register
• Any ongoing IT tickets linked to the user are closed or reassigned

1. 1Go to Offboarding in the sidebar. Find the pending case.
2. 2Review the staff member's details and departure reason.
3. 3Tick all required IT confirmation checkboxes.
4. 4Click Confirm IT Steps Complete. This updates the offboarding record and notifies HR that IT has signed off.

Once HR flips an offboardingRequests doc to status: completed, an automatic Cloud Function chain takes over server-side. IT does not need to do anything here — this section is documented so you understand the chain and can support SA / HR queries.

The Super Admin can bypass the offboarding workflow entirely via SA Control → Delete User. This is for test accounts, GDPR removal requests, and stale records where the full HR offboarding ceremony isn't needed.

The same chain runs: staff sweep → applicant sweep → combined cert → archive → GAS. Two SA-controllable checkboxes on the panel:

• Also wipe applicant trail (default ON) — sweeps the original applicant record via the personalEmail join. Untick only for a planned re-hire scenario where the original application should be preserved.
• Fire Google Workspace deprovision (GAS) (default ON) — untick to keep the mailbox temporarily available for handover.

SA Control also has a separate Delete Applicant tab for purging applicants who never converted to staff (rejected, withdrew, abandoned). Same engine, no GAS step. Same Deletion Certificate ends up in All Docs.

Every deletion — offboarding-driven OR SA-direct — writes a minimal record to the deletedPersonsRegistry Firestore collection (name, both emails, applicantId, previousUid, deletion date, reason, cert URL). HR can read this; IT can support SA queries by referencing it.

The HR recruitment-pipeline Re-Hire Warning reads from this registry. When HR adds a new applicant whose email or name matches a previously-deleted person, a red callout fires on the duplicate-check panel showing the prior deletion record with a direct cert link. HR can still proceed (warn-and-proceed policy) — every override is audited.

When you register an applicant as staff/volunteer, everything they submitted during recruitment (forms, signed offer/agreement letters, passport & website photos, and their government ID) still lives in the applicant system — HR can't see it in the person's Personal File. The Document Handover section copies it all across in one action, so HR has a complete file from day one.

The ID is copied too, but it lands locked in the Personal File. No HR user can open it directly. To view it, HR must request approval from the VMEM, who approves or declines — every request and decision is audited. You don't need to do anything extra; just be aware the ID is guarded by design.

• Only people registered from a recruitment applicant appear here — a manual account with no applicant trail won't show (there's nothing to copy).
• The handover is safe to run more than once; it's idempotent.
• The welcome email is still sent at registration — the handover is a separate, later step.

The Profile Health section lists staff members with missing critical fields (photo, nationality, phone number, emergency contact). Each staff member's missing fields are listed with a count.

IT's role here is awareness — contact the staff member and ask them to complete their profile via the My HR Record page. IT can also update fields directly via the Staff Directory if given the information.

Staff can request changes to protected fields (biological sex, gender, nationality, emergency contact, etc.) via their My HR Record page. These requests appear in the Profile Changes section filtered to Pending by default.

1. 1Review the requested change — the old value and new value are shown side by side.
2. 2If valid, click Approve & Apply. The user's Firestore record is updated immediately.

1. 1Enter a reason in the note field (required).
2. 2Click Decline. The reason is saved and visible to the staff member.

If you are uncertain whether a change is legitimate (e.g. a name change that may need documentation), enter your question in the note field and click Query HOD. The request is marked as Queried and the HOD is made aware.

The security score (0–100) reflects the live health of the DTTASA portal. It is computed in real time from multiple signals:

Below the score cards is the event feed. Use the filter tabs to view events by severity tier: All · Critical · Warning · Info. Each event shows the staff member, time, and available actions.

For any event, click the action buttons:

• Resolve — clears a lockout or ends a stale shift
• Nudge Profile — sends an automated email prompting the staff member to complete their missing fields
• View — opens the staff member's detail in the directory

1. 1Click Log Incident in the Incident Management section header.
2. 2Enter a clear title (e.g. "Portal login failures — 3 users affected").
3. 3Select the severity (P1–P4) based on impact.
4. 4List the affected systems (e.g. "Firebase Auth, Portal Login").
5. 5Write a description — what happened, when, and who is affected.
6. 6Click Log Incident. The incident is created and visible to all IT staff immediately.

As the incident progresses, click Add Update on the incident card to add timestamped progress notes. Use updates to keep the team and SA informed without creating new incidents.

Once resolved, click Resolve. Enter resolution details — this is mandatory. The incident closes and the timestamp is recorded.

A Super Admin can add a SA Directive — a gold banner displayed on a P1 or P2 incident card with specific instructions (e.g. "Do not resolve until legal is notified"). Always follow SA directives as written. Do not resolve an incident with an active directive without SA sign-off.

The IT Feedback page shows how staff rated the IT support tickets they raised (star ratings, averages, distribution, per-staff breakdown). It reads the itTicketFeedback collection. As of 2026-05-31 it is accessible to every IT-department user — not just IT admins — from IT Feedback in the dashboard's Departments menu.

Super Admins get a combined Feedback Centre (Feedback Centre in the Administration menu) that puts both feedback streams in one page, clearly separated by tab:

• IT Ticket Feedback — the same ticket-satisfaction ratings (avg, total, low-score count + recent list).
• Org Feedback & Surveys — organisation-wide feedback responses, surveys, and survey responses (orgFeedback / orgSurveys / orgSurveyResponses).

Each tab links out to its full page for deeper management. The Feedback Centre is a read-only overview — it uses one-shot reads (no live listeners) to stay zero-cost.

Every DTTASA staff member has an access level (L1–L5) stored on their user profile. This level controls which portal sections they can access and what actions they can take.

The Access Control Matrix (SA only) shows all staff with their current level. Use the dropdown on any row to change their level. You will be asked to confirm the change — confirm only if you have SA authorisation to do so.

Every level change is logged immediately to the Audit Log with the before/after values and your name.

The Firestore rules use isAdmin() as the broadest check — it covers both SA emails and anyone with accessLevel ≥ 4. isITDept() checks the department string only and can miss SA or IT Head users with a different department value. Always ensure rules use isAdmin() as a fallback for cross-user writes.

1. 1Click + Add Asset in the Asset Register section header.
2. 2Enter the Asset Name and select a Category — both required.
3. 3Set the Status: Active (in use), In Storage, Retired, or Lost/Stolen.
4. 4Optionally enter the Serial Number, Purchase Date, and Warranty Expiry.
5. 5Enter who it is Assigned To (staff member or "Organisation").
6. 6Click Save Asset. A unique Asset Tag (e.g. DTTASA-XK93TZ) is auto-generated and shown in the table.

Assets with a warranty expiring within 30 days show an amber ⚠ YYYY-MM-DD badge. Assets where the warranty has already expired show a red Expired badge. The row is also tinted to draw attention.

Action: contact the vendor or SA regarding renewal before the warranty lapses.

Use the status dropdown directly on each table row to change an asset's status without opening the edit modal. Use the category pills and status filter bar at the top to narrow down the list. Search by name, serial number, asset tag, or assigned person.

1. 1Click ✏ Compose in the IT Announcements section header.
2. 2Enter a clear Title (e.g. "Scheduled maintenance — Sunday 02:00–04:00 UTC").
3. 3Write the Message with full detail. Be specific — include times, affected services, and any actions staff need to take.
4. 4Set Priority: Normal, Urgent, or Critical.
5. 5Set Target Audience: All Staff or IT Department Only.
6. 6Click Broadcast. Delivery happens immediately.

1. 1Click Schedule Window in the Maintenance Windows section header.
2. 2Enter a Title describing the work (e.g. "Firebase rules deployment").
3. 3Set the Start and End date/time. Use UTC or specify the timezone in the title.
4. 4List Affected Systems (e.g. "Portal login, Firestore").
5. 5Write a Description of what will be done and any expected impact on staff.
6. 6Check Notify Staff to send an announcement email to all staff via the mail queue.
7. 7Click Schedule.

Click Mark Complete once the maintenance work is finished. Always mark complete even if it finished early — this updates the live status visible to all staff. If a window needs to be cancelled, click Cancel Window and provide a reason.

All emails sent by the portal (welcome emails, password resets, PIN links, announcements, notifications) are written to the mail Firestore collection. A mail router (Cloud Function) picks each one up and sends it via the first provider in the chain with free quota left: Resend (primary, 100/day · 3,000/month free) → Firebase Trigger-Email (SMTP, final overflow). Emails carrying attachments always use the SMTP path. The Mail Queue section lets IT see the current state of every outbound email.

At the top of the Mail Queue section (and in SA Control → Mail Engine) live per-provider cards show Today and Month send counts against each free cap, which provider is currently ACTIVE, and the last failure. Pip colours: green = healthy · amber = over 80% of a cap · red = exhausted or failing (mail is flowing to the next provider) · grey = provider not yet configured. Below the cards, Recent dispatches is a live log of the last sends with provider and status.

For any ERROR email, click Retry on the row. This clears the delivery record and asks the router to send it again through the full provider chain (Resend first, SMTP fallback) — the result lands back on the row within seconds. If all emails are failing, click Retry All Failed in the error banner at the top.

Click Auto-Refresh to enable a 30-second polling timer — useful during active incidents or after sending a bulk email to confirm delivery. The button turns green while active. Auto-refresh stops automatically on sign-out.

If a staff member forgets to clock out and their shift clock keeps running well past its scheduled end, the portal closes the session automatically so it does not count false hours. When that happens, a case appears in the Shift Investigations section of the IT board, and IT is emailed at it@dttasa.org. This is IT's to handle first, not HR's and not the Volunteer Manager's.

1. 1Open the Shift Investigations section. Each open case shows who, which day, and how far past the scheduled end the clock ran.
2. 2Contact the staff member to find out what happened and why they did not clock out.
3. 3If the shift needs entering, click Record the shift to open the attendance log and enter the real start and finish.
4. 4Click Mark resolved and add a short note of what happened, which is kept on the record.

If the matter needs a decision above IT, click Escalate and choose who to send it to:

• •the Volunteer Manager (for a volunteer),
• •the Head of Operations, or
• •the Head of IT.

You can add a note for them. They are notified in the portal with the details, and the case is marked Escalated so everyone can see where it sits. If a role has not been assigned to anyone yet, that option is greyed out.

The Probation Monitor lists every staff member with their probation status. Governance (Super Admins and Executives) are excluded, exactly as they are from rotas and HR grids. The data comes from the same probation fields HR maintains, so it is always current.

• •On probation: still within their probation period. The "time remaining" column counts down to the probation end date, and flags when a review is overdue.
• •Passed: probation completed successfully.
• •Failed: probation was not passed.

The three KPI tiles at the top show how many staff are in each state. The sidebar badge shows the number still on probation, so you can follow up without opening the section.

Only IT can publish staff to the public website, and only once they have passed probation. Every staff member who has Passed shows a Publish to website button on their row.

• 1Filter to Passed (or find the person in the list) and click Publish to website on their row.
• 2The system finds the website photo HR verified when the staff member submitted it during onboarding, and shows it. If they never submitted a dedicated website photo, it falls back to their profile photo and labels it as such, so you can still publish, and you review it again in the Admin Console before it goes live.
• 3Confirm their role / title as it should read on the public page, and add a short bio (optional). Click Push to website.
• 4The profile is carried securely to the Website Leadership queue of the public-website Admin Console. Open it there and click Publish to website to make it live on dttasa.org/leadership. You can also decline it there.

Once a staff member is live, their row shows On website with the role that is showing, and an Edit website details button instead of Publish. Use it to change their role / title or bio at any time. The form opens pre-filled with what is currently live, so you only change what you need. Saving sends it back through the same Website Leadership queue in the Admin Console for you to publish, so nothing changes on the public page until you confirm it there.

This whole rail is IT-only: there is no Communications approval step. What IT publishes is what appears on the public leadership page.

The Metrics Dashboard shows the following KPIs for the selected time period (7 days, 30 days, or 90 days):

Use the metrics to identify patterns: a high SLA breach count in 7 days suggests a staffing or prioritisation issue. Low satisfaction scores with high ticket volume suggest service quality needs attention. Use the 30-day view to compare against previous periods.

Click Refresh to reload metrics data (it is fetched once per section visit and cached for that session).

Test Mode routes all Firestore writes to shadow collections prefixed with test_ (e.g. test_itTickets instead of itTickets). It also suppresses all outbound emails. Use it when testing new features or bulk operations without affecting real data.

Enable/disable via System Config → Test Mode toggle. This changes the global flag for all IT Board users simultaneously.

Maintenance Mode shows the Under Maintenance screen to staff on the board pages — excluding the IT Board, so IT staff keep full access to do the work and toggle it off. SuperAdmins also keep full access everywhere. Use it during major deployments or when the portal is genuinely unavailable.

Staff can still sign in and view their home dashboard — where a gold maintenance notice appears at the top — but the moment they open a board or section (HR, Ops, Leave, etc.) they see the maintenance screen. SuperAdmins and IT see the MAINTENANCE MODE ACTIVE banner instead, with a DISABLE button.

Toggle via System Config → Maintenance Mode. Optionally set system/config.maintenanceMessage to control the exact text of the dashboard notice staff see (e.g. when service resumes).

The Audit Log records every significant IT action: registrations, password approvals, access level changes, bulk operations, system config changes. Entries are write-only — nobody can edit or delete them.

Use the category filter tabs (Registration, Credentials, Onboarding, Access, Bulk, System) to narrow results. Use the search bar to find actions by a specific team member.

SA can export the current filtered view as a CSV file using the Export CSV button — useful for compliance reviews.

The public-facing status page (portal.dttasa.org/system-status.html) shows the current state of each portal component. IT updates this manually during incidents so that staff and external stakeholders can see what is affected. Open it from the sidebar System Status nav item.

When IT Head or SA need to deploy code changes: run npm run deploy from the project directory. This builds and minifies all files into dist/ and pushes to Firebase Hosting. Firestore rules must be deployed separately with firebase deploy --only firestore:rules.

Diagnostics (portal.dttasa.org/diagnostics.html) is the live operations monitor for the portal. It streams the errorLog collection in real time, shows portal health, active sessions, and outbound mail status. Access is restricted to the IT Department, Head of IT, and Super Admins only. The heart-pulse ♥ icon in the HR Ops Monitor header links here and lights up red when unresolved HR-related errors exist.

Directly below the header is the Data-Source Assurance strip. It exists to remove any doubt about which data you are looking at, because the rest of the portal can route a session to shadow collections (Test Mode → test_*, demo accounts → demo_*). Diagnostics deliberately reads through the raw Firestore SDK, so it is routing-immune — it always shows production. The strip surfaces that guarantee plus live context:

In normal operation you should see PRODUCTION (green), Portal Test Mode: OFF, and Session Demo: OFF. That confirms every figure on the page reflects real, live portal data.

A monitoring tool that silently showed test or demo data would be worse than no monitor at all — IT could believe production is healthy while looking at sandbox figures. The Data-Source strip makes the guarantee explicit and continuously visible, so anyone reading Diagnostics knows, at a glance, that they are seeing the real portal.

The Live Error Feed streams errorLog in real time. To stay fast and keep Firestore reads low it is deliberately bounded — it shows the last 24 hours, newest 200 errors. The filter tabs (All · Unresolved · Escalated · Resolved · Transient), the search box, and the ⏸ pause button all work on this live window.

If errors arrive faster than they are resolved, or an unresolved error is older than 24 hours, it sits outside that live window and will not appear on its own. Use the ↻ Load every error button (next to pause) to pull every recent error regardless of age — it does a one-time, time-unbounded fetch (up to 1000) and merges it into the feed, so nothing waiting beyond the live window is ever missed. From then on the live stream keeps merging new errors in rather than shrinking back to the window.

Both sit at the top of the sidebar: Help Desk (tickets staff have raised) and Live Chat (real-time sessions waiting or active). The red badge on Help Desk counts active tickets; the green badge on Live Chat counts waiting chats.

Use the filter row at the top — ALL · OPEN · IN PROGRESS · AWAITING STAFF · RESOLVED · ESCALATED TO HOT · ESCALATED — to narrow the list. Each card shows the reference (last 6 of the ID), priority (P1–P4), status, SLA badge, subject, submitter, department, category, and assignee. Click a card to open its drawer.

1. 1Set the Priority (P1–P4) — this resets the ticket's SLA respond/resolve deadlines.
2. 2Use the Assign To dropdown to assign the ticket to yourself or another IT colleague.
3. 3Type in the Reply box and click Send. Tick Internal note to record a comment only IT can see (not sent to the staff member). Replying to an OPEN ticket moves it to IN PROGRESS automatically.
4. 4Use the action buttons: Mark In Progress, Awaiting Staff (waiting on the submitter), or Resolve.
5. 5AI Help drafts a suggested answer to paste into your reply — always review it before sending.

The Live Chat section shows two groups: WAITING (staff who have opened a chat and need picking up) and ACTIVE (chats currently being handled).

1. 1On a waiting chat, click Pick Up. This claims the chat, marks it ACTIVE, and posts a "support agent has joined" line.
2. 2Click Open Chat to open the live message window. Type a message and press Enter (or the send button) — messages stream in real time both ways.
3. 3If the issue needs tracking beyond the chat, click To Ticket — this creates a P3 Help Desk ticket pre-filled with the chat transcript, assigned to you, then jumps you to the Help Desk.
4. 4When finished, click End Chat. A resolution note is required — it's posted to the chat and saved on the session before it closes.

The Verified App. Photos section is a read-only gallery of every applicant whose ID photo HR has reviewed and verified. Each card shows the passport photo (with an initials fallback if the image fails), a VERIFIED tag, the applicant's name, the position applied for, their email, who verified it and when. If a full-body / website photo was also provided, it appears alongside.

Use the search box to find an applicant by name, position, or email. View Passport Photo and View Website Photo open the full image in a new tab.

The Applicant Portals section tracks every applicant portal account created during recruitment. The amber sidebar badge counts portals still on a temporary password. A summary strip shows Total Portals · Signed In · Password Set · Temp Password.

Each row shows the applicant's name, email, the role + department they applied for, when their portal was created, and two status badges:

Filter by Temp Password · Password Set · Signed In · Never Signed In, or search by name, email, position, or department.

Doc Access Blocks live in the Password & PIN Resets guide — IT confirms a block HR has initiated when a compliance document expires. This entry notes the connection: when an applicant converts to staff at registration, the system links the new users record back to the original applicant record. That link is what later powers offboarding's applicant sweep and the recruitment Re-Hire warning (covered in Staff Registration & Accounts and Offboarding IT Confirmation).

The Security Alerts section is the live triage feed of flagged sign-in events. Filter tabs are Open · Acknowledged · All, and the header counts Threats · Reviews · Open · Acknowledged. Each row shows the staff member, threat level (Threat / Review / Safe), reason, IP + location, device label + fingerprint, and date.

1. 1Review each open alert — check the IP, location, and device against what you'd expect for that person.
2. 2If it's legitimate, click Ack to acknowledge it. The alert is stamped with your identity and time.
3. 3If it's suspicious, escalate to the Head of IT or SA before acting. Device trust/block is handled from the Consent & Location drawer (below).

Use the Show N of total selector to page through larger volumes (10–5000).

The Consent & Location table is the per-user compliance view. The stat strip counts OK / Review / Threat plus consent-pending, consent-declined, and location-denied users. Each row shows threat level, consent status (Accepted with version + date, Declined, or Not yet shown), location-permission status, IP + location, device, and last fix time.

• Map opens the user's last known location in Google Maps (when a fix exists).
• Details opens a drawer listing that user's known devices, where you can Trust or Block a device. Blocking signs the user out of that device shortly after.

Rows sort issues-first (threats, then reviews, then missing consent, then denied location). Filter by bucket or search by name, department, country, city, device, or IP.

The Suspensions section is a read-only register of suspended staff: name, reason, suspended-on date, until date (or Indefinite), who issued it, and whether it is Active or Expired. Active suspensions also deduct from the Security Score (see SOC Monitor & Security Score). Suspensions are issued elsewhere (HR / SA) — IT views them here for awareness.

The Stale Shifts section flags active shifts that look stuck — either running 10+ hours or started on a previous day (an overnight crossing). The day boundary is anchored to West Africa Time, matching the timer. Each row shows the staff member, department, clock-in time, elapsed hours, and a Long shift or Overnight tag.

1. 1Contact the staff member to confirm they simply forgot to clock out.
2. 2Click End Shift. A reason is required — it's recorded with your IT officer details in the final PDF timesheet. No user signature is needed for an IT-terminated shift.

The Applicant Activity section is a live visitor feed for the public recruitment pages. The stat strip counts active-now, today's visitors, forms started, forms submitted, and distinct countries. Each row is an anonymous visitor: an online pip, the page they're viewing, IP + location, device, form status (Browsing / Started / Submitted), session start, and last-seen time. The table paginates (10/page on mobile, 50/page on desktop) and is searchable by IP, country, city, page, or device.

The Idealist Postings section mirrors the volunteer/role adverts posted to Idealist. Each entry shows the position title, department, when it was posted (WAT) and by whom, with an Open button to the live listing. The amber badge counts postings from the last 7 days. This is a visibility feed only — IT doesn't edit Idealist from here.

The Team Accountability section lets a head of department raise people-management items about their own team without leaving the IT Board. There are two actions in the header: Log Absence and Lodge Incident. Every report you submit forwards to the Head of HR for review — you are filing it, HR acts on it.

1. 1Click Log Absence. Pick the staff member and the date (defaults to today).
2. 2Add notes describing the absence (e.g. reported sick, no-show, late notice).
3. 3Submit. The absence record is forwarded to HR.

1. 1Click Lodge Incident. Pick the staff member, the incident date, and the type: Conduct, Latency/Tardiness, Unsubmitted Shift, Training Non-Compliance, Dual Employment, or Other.
2. 2Write a clear factual description of what happened.
3. 3Submit. The incident is created with status Pending HR Review and lands in the Head of HR's queue.

Below the buttons, "Pending reports you have submitted" lists the items you raised that are still awaiting HR, each with the subject, type, incident date, and lodged date, marked PENDING HR. The red sidebar badge counts these. Once HR actions a report it drops off this list.

The Handbook Library section lists every handbook category and the documents filed under it. The header shows the category and document totals and an Open Full Handbook Page link. Each category is colour-coded and shows its document count and display order; each document shows its title, the departments it's visible to, file type, and version.

1. 1Use Publish / Unpublish on any document to flip its LIVE / DRAFT state instantly.
2. 2Use the red trash button to delete a document — you'll be asked to confirm. Deletion cannot be undone.
3. 3To add categories or documents, or change ordering, open the full handbook page via the header link.