Goal

Описать логику работы админ панели, для просмотра статистики в разрезе рекламных компаний, с возможностью гибкого управления доступами.

Входные данные

У нас есть таблица в BQ, со следующими колонками

Для нас важны:

• customerId: ид аккаунта, используется как срез для управления доступом
• inserted_at: дата вставления данных, необходима для всех отчетов
• vertical: вертифкаль рекламы, используется для управления доступом

Сценарии

Баер

Я как баер:

• хочу зайти в систему, увидеть принадлежащие мне рекламные компании, увидеть принадлежажие мне рекламные аккаунты. Я хочу иметь возможность просмотреть все отчеты, по доступным мне аккаунтам, рекламным компаниям
• хочу иметь возможность сменить свой пароль
• хочу иметь возможность выгрузить данные отчета в csv\excel

Тим Лид

Я как тим лид хочу иметь все возможности баера плюс:

• хочу иметь возможность создать нового пользователя с ролью баер. Для этого мне необходимо внести емейл пользователя и стартовый пароль
• хочу иметь возможность сбросить пароль баера
• хочу иметь возможность изменить стату баера на “disabled”
• хочу иметь возможность управлять доступом баеров к компаниями
• хочу иметь возможность задавать таргет по затратам для каждого аккаунта

Админ

Я как админ хочу иметь возможности тим лида, плюс:

• хочу иметь возможность повысить баера до тим лида
• хочу иметь возможность управлять доступом тим лидов к компаниям

ERP

Я как ERP система хочу возможность програмно менять права доступа, для этого необходимо реализовать метод set-permissions. К примеру: POST /api/set-permissions

{
users:
  [
     {
        accountEmail: "[email protected]",
        role: "buyer", // team-lead, admin
        accounts: [
           "gacc1", "gacc2", "gacc3"
        ]
     }
  ]
}

для авторизации должен использовать authorization заголовок, оговоренный заранее с ERP. Если пользователь с заданным емейл не существует — необходимо его создать (далее пользователь сможет залогинится через сброс пароля). Если в массиве account указанны несуществующие акканту — никаких действий предпринимать нет необходимости.

Техническая реализация

Как механизм визуализации мы используем metabase. Это означени что мы можем быстро конфигурировать views в bigquery и выводить их как embedded блок в виде iframe внутри продукта.

ACL

Проблема состоит только в том, что metabase read only база данных для metabase. Поэтому мы вынужденны завести несоклько новых таблиц, для управления доступами.

Таблица users

• accountEmail: емейл пользователя, используется как ключ для определения прав
• role: роль связанная с пользотвателем

Таблица acl

• user_email: емейл пользователя, из таблицы users
• customerId: ид рекламного аккаунта
• access: read/none

Далее я предлагаю сделать view, где использя join получить join data со всеми пользователями из ACL.

Это неэффективный путь с точки зрения работы с данными, но он позволяет использовать нативные функции метабейса для фильтрации только разрешенных полей из таблицы с данными.

То есть мы получим таблицу вида:

TargetSpend

Управление целевыми параметрами аккаунта. Параметр который нас просят сделать - соотвествие целей по затратам на аккаунте целевому значению. Для этого мы берем сумму costMicros для каждого аккаунта, и смотрим будет ли он больше целевого, или меньше целевого. Поскольку для каждого аккаунта задается индивидуальная цель, то предлагается завести отдельную таблицу в BQ, на подобие ACL, в которой можно был бы записать целевые параметры таргета.

Список экранов

Оригинал моков

Экран логина

Экраны отчетов

Отечеты группируются в боковом меню, отчетов может быть много (к примеру stats и spend). Каждый отчет педставляет собой metabase dashboard, в который в виде скрытого фильтра передан email текущего пользователя.

Экран списка пользователей

На этом экране мы средствами kit делаем запросв BQ и выводим таблицу (не метабейс таблицу) На этом экране должна быть опция добавить пользователя, или отредактировать уже сущесвтующих пользователей. Экран доступен только для ролей admin либо teamlead (с фильтром по parent). Оптимально сделать хранение этих параметров через EAV, по аналогии с тем, как это сделанно было в SOT. В этом случае мы будем иметь так же историю изменения прав доступа.

Экран аккаунтов

Экран просмотра доступов. На этом экране видно какой пользователь имеет доступ к какому аккаунту. Я не предлоплагаю что будет возможность редактироать права доступа. Для управления доступами используется апи.

Экран Цели

Экран необходим для установки целей для аккаунтов. Цели так же предлагается в виде EAV хранить. Таким образом если когда-то у аккаунтов появятся какие-то дополнительные поля - мы легко сможем расширить представление.

Экран профиля

Необходим для смены пароля пользователем. При создании пользователя он получает пароль от администратора, и далее может установить пароль сам.

TBD (out of scope)

Turnstile

Возможно имеет смысл добавить turnstile (скрытую каптчу) для флом авторизации

Audit log

Возможно имеет смысл сохранять историю сесий (логинов), кто, когда, с какого IP логинился.

RBAC editor

Возможно имеет смысл сделать визаульный редактор прав пользоватлей, а не просто визуализировать права. Я не уверен что это имеет смысл, если доступы будут приходить из ERP.