- Ya
- 21 Agosti 2026, 01:05 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 59221aa
Three things, all about a support desk that answers more than one tenant. The ticket detail now carries a per-viewer verdict on whether to offer "open the requestor's org as the System User", resolved by the shared SupportSystemAccessResolver — the same class SecurityService re-runs before minting anything, so nothing here can grant access, only reveal it. The one condition added locally is about the CONVERSATION rather than the grant: never the requestor's own button. It could not be minted anyway, but a support window offering the customer an administrative door into themselves is alarming whether or not the door opens — and on a widget ticket the "requestor" is the org's system member, who is usually the person working the queue. MediaService is also where that access ENDS. Reassigning, escalating, moving an assigned ticket and closing or resolving one all recheck the agent who lost it against the requestor's organization; the revoker re-derives from the database, so an agent with another open ticket from the same org — or the blanket SYSTEM_USER right — keeps their session and no caller has to work that out. Rechecks run afterCommit: re-reading rows this transaction just wrote is what raises a 40001 restart on YugabyteDB, which would take the reassignment with it. The previous agent keeps the CHAT, deliberately — that is the point of reassigning rather than reopening — but not the tenant. Every mutation endpoint re-answers the verdict on the way out, because the window swaps in whatever they return and toDTO knows nothing about who is looking; without it the button vanished the moment an agent touched the priority dropdown. It is a void side effect rather than a wrapper that returns the ticket: the wrapper form turned the entire response body into null wherever this service is mocked, which the controller tests caught. Finally, requestorOrgName / requestorOrgIsPlatform on the ticket (bulk-loaded on the list path — requestorOrg is lazy and a queue is rows from different orgs by definition), and org, status and ticket age on the Chats-feed support rows. Age is the ticket's creation, not lastActivityAt: a quiet three-day-old ticket reads as fresh by activity and is the most urgent row on the list.