SubmissionConversation

Corex\Config\Submissions\SubmissionConversation · class · Config layer

The conversation a reply to a submission can be sent in: the emails its sender was already sent about it, in order (spec 106, FR-038). Read from what is already kept: what a site said it sent itself, the emails a flow sent and bound to the submission, and each reply’s sendings. Which of a flow’s emails and of the replies the person really has, and under which id, is the email add-on’s to say. A site that sends its own confirmation through CoreX’s mailer tells CoreX so, once, where it sends it, with the request it sends: $request = new MailRequest(to: [$email], subject: $subject, body: $html); $mailer->send($request); $conversation->began($submissionId, $request); Replies to that submission can then be sent under that confirmation. The request is what is recorded, and not what became of it: the email may be waiting in a queue, and it leaves under an id made of the request’s own whenever it does.

Public API

__construct(SubmissionReplyStore $replies, SubmissionConversationStore $own, SubmissionEmailGateway $email, SubmissionWorkflowStore $submissions, string $host)

of(array $record): ReplyConversation

began(int $submissionId, MailRequest $request): void

Records an email a site sends the submission’s sender itself, so that replies continue from it. Only an email that goes to the person who sent the submission: a site’s listener sends the team’s notice from the same place, and a reply to a customer must not answer, or be headed by the subject of, an email they were never sent. Nothing is recorded where the site has no host to make an id of.