Дмитрий
efcb8034a0
Хвосты Этапа 1 (журнал В-37). Строк приёмочного листа не закрывают — уборка. 1. Графа «кто внёс» в общем стоп-листе портала снесена. Она была не пустой, а врущей: при открытом в том же браузере обычном кабинете туда записывался id КЛИЕНТСКОГО пользователя — число, неотличимое от id администратора. Проверено пробой: пользователь 1 → в графе 1. Админ-зона закрыта паролем nginx, своего входа Laravel у неё нет, а сессия кабинета видна и там — то же эхо коллизии 24.07. Заполнить правдой нечем: настоящий вход админа ждёт Б-1, соседние экраны пишут id служебной заглушки, то есть одно число во всех строках. Остались номер, причина словами и дата — этого хватает и для разбора жалобы, и для договора с МТС. Возврат — down() миграции. 2. Все 16 миграций модуля начинаются с «уже сделано — выходим», уникальный индекс ключа заказа создаётся с IF NOT EXISTS. Причина не теоретическая: на бою SQL миграций подаётся в базу руками, памяти «этот файл уже применён» там нет. У тарифов и настроек это особенно важно — они засевают строки, и повторный запуск завёл бы ВТОРУЮ строку настроек молча, без ошибки. 3. Восемь GRANT … TO crm_app_user стояли без проверки существования роли — на чистой базе migrate падал бы целиком. Теперь все в гарде, как в v9.00 и v9.07. Своя ловушка гарда: опечатка в имени роли внутри IF EXISTS ошибки НЕ даёт, права просто не выдаются — а это ровно блокер выката В-36. Поэтому заведён сторож: тест спрашивает у самой базы has_table_privilege / has_sequence_privilege по каждой таблице и счётчику модуля. Заодно закрыта дыра — у фикса В-36 теста не было вовсе. Хвост «7 замечаний squawk» проверить его же инструментом нельзя: squawk читает SQL, а миграции у нас PHP. Чужой отчёт не пересказываю — проверка своя и воспроизводимая: тест прогоняет up() каждой миграции второй раз. Тесты: +3 (повторный запуск, права ролей, «чужого следа не остаётся»), один переписан. ClientSms 169/169, приём лидов 17/17, phpstan 0, pint чисто. Три выреза, все покраснели: испорченное имя роли, снятая защита от повторного запуска, возвращённая графа. Живой прогон: вошёл в обычный кабинет (та самая опасная обстановка), внёс номер через админ-раздел — в базе ровно три поля, чужого следа нет; убрал кнопкой. Пять миграций запущены по второму разу прямо на dev-базе — прошли, тарифов 5, строка настроек одна. Контроль: голый CREATE TABLE та же база отвергает. Запись схемы — v9.10.
89 lines
4.3 KiB
PHP
89 lines
4.3 KiB
PHP
<?php
|
||
|
||
declare(strict_types=1);
|
||
|
||
use Illuminate\Foundation\Testing\RefreshDatabase;
|
||
use Illuminate\Support\Facades\DB;
|
||
|
||
/**
|
||
* Сторож прав рабочей роли на таблицы модуля.
|
||
*
|
||
* Зачем он появился (Task 8). В миграциях модуля права выдавались строкой
|
||
* `GRANT … TO crm_app_user` без проверки, есть ли такая роль: на чистой базе это
|
||
* валит `migrate` целиком. Проверку я добавил — но у неё есть своя опасность:
|
||
* опечатка в имени роли внутри проверки НЕ даёт ошибки, права просто молча не
|
||
* выдаются. А это ровно тот блокер выката, что стоил нам дня 27.07 (журнал В-36):
|
||
* на бою первая же запись падает с «нет доступа», а тесты и локальная база этого
|
||
* не видят — там суперпользователь.
|
||
*
|
||
* Поэтому здесь проверяется не текст миграции, а результат: реально ли у роли есть
|
||
* право писать в каждую таблицу модуля и пользоваться её счётчиком.
|
||
*
|
||
* ⚠️ Честное ограничение: тест доказывает это только там, где роли заведены
|
||
* (`db/00_create_roles.sql`). Где ролей нет — он пропускается и не доказывает ничего.
|
||
*/
|
||
uses(RefreshDatabase::class);
|
||
|
||
/** Таблица → права, которые модуль обещает рабочей роли. */
|
||
const CLIENT_SMS_TABLE_GRANTS = [
|
||
'client_sms_campaigns' => ['SELECT', 'INSERT', 'UPDATE'],
|
||
'client_sms_campaign_phones' => ['SELECT', 'INSERT', 'DELETE'],
|
||
'client_sms_messages' => ['SELECT', 'INSERT', 'UPDATE'],
|
||
'client_sms_optouts' => ['SELECT', 'INSERT', 'DELETE'],
|
||
'client_sms_contacts' => ['SELECT', 'INSERT', 'DELETE'],
|
||
'client_sms_templates' => ['SELECT', 'INSERT', 'UPDATE', 'DELETE'],
|
||
'client_sms_tariffs' => ['SELECT'],
|
||
'client_sms_settings' => ['SELECT'],
|
||
'client_sms_senders' => ['SELECT', 'INSERT', 'UPDATE'],
|
||
'client_sms_auto_rule' => ['SELECT', 'INSERT', 'UPDATE'],
|
||
'sms_global_optouts' => ['SELECT'],
|
||
];
|
||
|
||
function clientSmsRoleExists(string $role): bool
|
||
{
|
||
return DB::selectOne('SELECT 1 AS ok FROM pg_roles WHERE rolname = ?', [$role]) !== null;
|
||
}
|
||
|
||
it('у рабочей роли есть обещанные права на таблицы модуля', function () {
|
||
if (! clientSmsRoleExists('crm_app_user')) {
|
||
$this->markTestSkipped('Роли crm_app_user на этой базе нет — проверять нечего.');
|
||
}
|
||
|
||
foreach (CLIENT_SMS_TABLE_GRANTS as $table => $privileges) {
|
||
foreach ($privileges as $privilege) {
|
||
$granted = DB::selectOne(
|
||
'SELECT has_table_privilege(?, ?, ?) AS ok',
|
||
['crm_app_user', $table, $privilege],
|
||
)->ok;
|
||
|
||
expect($granted)->toBeTrue("Роли crm_app_user не выдано право {$privilege} на {$table}");
|
||
}
|
||
}
|
||
});
|
||
|
||
/**
|
||
* Счётчики (sequence) — отдельная история: право на таблицу их НЕ покрывает, и
|
||
* именно этого не хватало всем 14 миграциям модуля до фикса В-36.
|
||
*/
|
||
it('у рабочей роли есть право пользоваться счётчиками таблиц модуля', function () {
|
||
if (! clientSmsRoleExists('crm_app_user')) {
|
||
$this->markTestSkipped('Роли crm_app_user на этой базе нет — проверять нечего.');
|
||
}
|
||
|
||
$sequences = DB::select(<<<'SQL'
|
||
SELECT sequencename FROM pg_sequences
|
||
WHERE schemaname = 'public' AND sequencename LIKE 'client\_sms\_%'
|
||
SQL);
|
||
|
||
expect($sequences)->not->toBeEmpty();
|
||
|
||
foreach ($sequences as $row) {
|
||
$granted = DB::selectOne(
|
||
'SELECT has_sequence_privilege(?, ?, ?) AS ok',
|
||
['crm_app_user', $row->sequencename, 'USAGE'],
|
||
)->ok;
|
||
|
||
expect($granted)->toBeTrue("Роли crm_app_user не выдано право на счётчик {$row->sequencename}");
|
||
}
|
||
});
|