Context
PR #4182 makes the RealUnit API auto-open a support ticket when an Aktionariat registration forward fails (status ManualReview — there is no retry cron, a human must re-forward). The ticket is created via SupportIssueService.createIssueInternal.
For the first message we had to pick a message author. We chose CustomerAuthor as a pragmatic workaround, because it is the only value that leaves the ticket unassigned / awaiting staff without side effects.
Problem
author is not a neutral label — createMessageInternal (support-issue.service.ts) branches on it:
if (dto.author !== CustomerAuthor) {
issue.setClerk(dto.author); // assigns the ticket to a "clerk" named after the author
supportIssueNotificationService.newSupportMessage(entity); // notifies the customer "support replied"
}
There is no neutral system author: only Customer and AutoResponder exist, and AutoResponder still hits this branch. So a semantically correct author for a system-opened ticket (e.g. 'System' / 'Api') would:
- assign the ticket to a phantom clerk named after the author → it looks handled and can drop out of the unassigned triage queue, and
- push a misleading "support replied" notification to a customer who never opened a ticket.
Using CustomerAuthor avoids both, but attributes the auto-generated first message to the customer, which is semantically wrong (the message text makes the automatic origin clear, so it is acceptable for now).
Proposal
Introduce a real neutral system author and make createMessageInternal treat it as neither a customer nor a clerk reply:
- Add a
SystemAuthor = 'System' constant next to CustomerAuthor / AutoResponder in support-message.entity.ts.
- In
createMessageInternal, only assign a clerk + fire newSupportMessage for a real clerk author — i.e. skip both side effects when the author is SystemAuthor (leave the ticket unassigned / awaiting staff, no customer notification).
- Switch the RealUnit forward-failure ticket (and any future system-opened tickets) to
SystemAuthor so the first message is correctly attributed to the system.
Acceptance criteria
- A ticket whose message author is
SystemAuthor is left unassigned (no phantom clerk), awaiting staff (Pending), and triggers no customer "support replied" notification.
- Existing behaviour for
Customer and real-clerk authors is unchanged.
- Unit tests cover the new author branch.
Notes
Context
PR #4182 makes the RealUnit API auto-open a support ticket when an Aktionariat registration forward fails (status
ManualReview— there is no retry cron, a human must re-forward). The ticket is created viaSupportIssueService.createIssueInternal.For the first message we had to pick a message
author. We choseCustomerAuthoras a pragmatic workaround, because it is the only value that leaves the ticket unassigned / awaiting staff without side effects.Problem
authoris not a neutral label —createMessageInternal(support-issue.service.ts) branches on it:There is no neutral system author: only
CustomerandAutoResponderexist, andAutoResponderstill hits this branch. So a semantically correct author for a system-opened ticket (e.g.'System'/'Api') would:Using
CustomerAuthoravoids both, but attributes the auto-generated first message to the customer, which is semantically wrong (the message text makes the automatic origin clear, so it is acceptable for now).Proposal
Introduce a real neutral system author and make
createMessageInternaltreat it as neither a customer nor a clerk reply:SystemAuthor = 'System'constant next toCustomerAuthor/AutoResponderinsupport-message.entity.ts.createMessageInternal, only assign a clerk + firenewSupportMessagefor a real clerk author — i.e. skip both side effects when the author isSystemAuthor(leave the ticket unassigned / awaiting staff, no customer notification).SystemAuthorso the first message is correctly attributed to the system.Acceptance criteria
SystemAuthoris left unassigned (no phantom clerk), awaiting staff (Pending), and triggers no customer "support replied" notification.Customerand real-clerk authors is unchanged.Notes
support-message.entity.ts,support-issue.service.ts(createMessageInternal), plus tests.