CoolCMS API

ComplaintEmailGenerator
in package

FinalYes

Renders the transition e-mails of a complaint, modeled on {@see OrderEmailGenerator} and simplified to a single template source: {@see \App\Core\Base\Shared\Eshop\Models\Entities\ComplaintStatusText::$emailSubject} / `$emailBody` (per `languageId`). A complaint has no generic system template and no shipping notice, only the status.

The e-mail is never sent directly: prepareStatusEmail() only renders it and the caller (ComplaintTransitionManager) inserts it into cms_system_email_queue via EmailQueueManager::enqueue() on the passed connection (transactional outbox, same transaction as the status write).

Rendering fails silently (null): a missing template (status without sendEmail, empty subject/body) and a render error (broken Latte template) both lead to null; no e-mail is preferred over an empty one without a log trace (see renderTemplate()).

Table of Contents

Constants

SETTING_MODULE_CORE  : int = 0
SETTING_MODULE_SYSTEM  : int = 1

Properties

$languageManager  : LanguageManager
$priceLatteExtension  : PriceLatteExtension
$settingContext  : SettingContext

Methods

__construct()  : mixed
prepareStatusEmail()  : PreparedOrderEmail|null
customerEmail()  : string|null
formatDate()  : string
itemValues()  : array<int, array{name: string, code: string|null, quantity: int}>
render()  : PreparedOrderEmail|null
renderSubject()  : string
The subject is also Latte in the database (`Complaint no. {$complaint['number']} …`). Without variables it is not rendered; on error the raw text stays (an e-mail with a worse subject beats no e-mail).
renderTemplate()  : string|null
resolveLanguageId()  : int
`order.language`, otherwise the site-wide default (the complaint itself stores no language).
settingPath()  : string
Returns the path from settings (`['abs']`) or throws a readable exception.
solutionName()  : string

Constants

Properties

Methods

formatDate()

private formatDate(mixed $date) : string
Parameters
$date : mixed
Return values
string

itemValues()

private itemValues(Complaint $complaint) : array<int, array{name: string, code: string|null, quantity: int}>
Parameters
$complaint : Complaint
Return values
array<int, array{name: string, code: string|null, quantity: int}>

renderSubject()

The subject is also Latte in the database (`Complaint no. {$complaint['number']} …`). Without variables it is not rendered; on error the raw text stays (an e-mail with a worse subject beats no e-mail).

private renderSubject(string $subject, array<string, mixed> $values) : string
Parameters
$subject : string
$values : array<string, mixed>
Return values
string

renderTemplate()

private renderTemplate(string $body, array<string, mixed> $values) : string|null
Parameters
$body : string
$values : array<string, mixed>
Return values
string|null

resolveLanguageId()

`order.language`, otherwise the site-wide default (the complaint itself stores no language).

private resolveLanguageId(Complaint $complaint) : int
Parameters
$complaint : Complaint
Return values
int

settingPath()

Returns the path from settings (`['abs']`) or throws a readable exception.

private settingPath(int $module, string $key) : string

IMPORTANT: SettingContext::get() returns null when the settings map was never populated in this run, which is exactly the CLI situation (harness, cron without web bootstrap). A direct …get(…)['abs'] would raise the warning "Trying to access array offset on null" and abort the whole CLI run although the complaint is already saved and the e-mail is best effort. The checked exception falls into the catch in renderTemplate(), is logged and the render returns null, which is what this class promises.

Parameters
$module : int
$key : string
Return values
string

solutionName()

private solutionName(mixed $solution, int $languageId) : string
Parameters
$solution : mixed
$languageId : int
Return values
string
On this page

Search results