Portal Managers Ideas

Portal managers: ideas not yet built

Blue sky thinking · Came out of building Portal managers (discussion #62), September 2026

Ideas noticed while building managers, confidential tickets and "who has seen this ticket". Each has had enough thought to know its shape and its catch; none is committed to. Several are small. They are grouped by what they would touch.

Already done from the same list, so not here: paging and a person filter on Team tickets; telling managers about new team tickets (email or the portal bell); keeping confidential tickets away from AI, chat posts and external trackers; and making emailed links use the one HTTPS rule.

---

Managers

An audit history of management lines

The idea. Every management line records who added it and when, but removing one leaves no trace. Granting somebody the right to read other people's tickets arguably deserves a full history: added, removed, by whom, when.

The catch. There is no general audit log to put it in. The tickets, changes and problems each have their own audit table, and nothing covers people or settings. Doing it properly probably means a small shared audit table for "security-relevant settings" (manager lines, then role and permission changes), which is a bigger decision than managers alone. A quick version - soft-deleting lines with removed_by / removed_datetime - is cheap but only ever answers this one question.

Where. manager_grants, api/tickets/manager_access.php (remove), the Manager access page.

---

The self-service portal

Everyone gets the bell: requester notifications

The idea. The portal bell (the same bell as the analysts') is shown to managers today. Requesters would earn one with three events: IT replied to your ticket, its status changed, it was closed. Most useful to people who live in the portal rather than their inbox - and to directory users with no mailbox at all, who today are told nothing.

The catch. Requesters already get emails for replies, so for most people the bell is a second copy; the case rests on the no-mailbox users and on portal-first organisations. It also needs a per-person choice (bell, email, both), or the bell becomes noise and gets ignored - the exact failure the analyst bell's noise rules exist to prevent.

Where. NotificationsService::notify() with portal_user_id already works; the events come from the reply, status and close paths in includes/services/tickets.php; self-service/includes/header.php decides who sees the bell.

Say so when a ticket goes in confidential

The idea. A ticket emailed to a confidential mailbox (HR) is confidential the moment it lands, but the person who sent it is not told until they open it in the portal. The acknowledgement email could say "this ticket is confidential: it is kept from managers".

The catch. Reassuring the sender also tells anyone reading their inbox over their shoulder that they contacted HR about something private. Probably a per-mailbox wording choice rather than on by default.

Where. The acknowledgement in api/tickets/check_mailbox_email.php, after ticketSensitivityApplyDefaults().

Read receipts

The idea. Record the requester's own portal views too, so an analyst can see "the customer has read your reply" - and stop chasing someone who has.

The catch. Only half the picture: most people read replies in their email, which records nothing, so "not read" would mostly be wrong. And a requester might reasonably not want the desk to know they read a reply and did not answer. Deliberately not done in step 2 for those reasons.

Where. ticketViewRecord() already takes a viewer type; api/self-service/get_ticket_detail.php records managers only.

---

People and directories

Lock a directory-owned name and email

The idea. A directory owns a person's job title, department and the rest, and the person editor greys them out. Their display name and email are synced too, but stay editable, and the next sync silently puts them back.

The catch. The email is also how some people sign in, and an analyst sometimes needs to correct an obviously wrong address before the directory is fixed. Locking it removes that escape hatch. Worth doing with a clear "change it in the directory" note, as the other fields have.

Where. USER_DIRECTORY_OWNED / userDirectoryOwnedFields() in includes/users.php, includes/directory_sync.php, includes/person_editor.php.

A company set by hand is reverted by the next sync

The idea. Change a synced person's company in the person editor and directory sync changes it back. Either sync should leave a hand-set company alone, or the editor should say it will not stick.

The catch. "Leave it alone" needs a record that the company was set by hand, which is a new column and a precedence rule - and the directory is usually right. Telling the analyst is cheaper and honest.

Where. The company step of includes/directory_sync.php; the person editor.

Tidy the Directory Sync page

Housekeeping, not an idea. Directory Sync §3.12 and §7.8 still describe an earlier plan: one System → Users screen. What was built instead is one shared person editor opened from Tickets → Users and Assets → Users (Contact details — Developer Guide §4). Reword those sections, or record why the screen was not built.

---

Tickets

Announce every new ticket, whatever the channel

The idea. A new ticket is announced once, by ticketDispatchCreated() - which drives ticket.created workflows, the analysts' bell, search indexing and now manager notifications. Tickets from web chat, WhatsApp and the request catalogue (and splits and merges) never call it, so none of those see them.

The catch. It is a behaviour change for anyone with a ticket.created workflow: rules that have never fired for web chat would start to. Worth doing, with a release note that says so, and checking each path applies the confidential defaults before it announces - the order manager notifications depend on.

Where. includes/webchat/webchat.php, includes/messaging/ingest.php, includes/catalogue_approvals.php, includes/ticket_split.php, includes/ticket_merge.php.

---

See also

• Portal managers · Developer Guide
• Blue sky thinking