Конструктор доступов

Контекст

Компания занимается телеизмерениями и предоставляет клиентам личный кабинет для построения отчётов.
Администраторы в панели управления выдают клиентам доступ к данным — с привязкой к городам и телеканалам.

Задача

В карточке клиента нужно было настроить выдачу доступов к городам и телеканалам так, чтобы каждому можно было задать свой период доступа, а не один общий, как раньше.

🤯То есть внутри города разные телеканалы могли иметь разные периоды доступа.

Решение

Конструктор доступов — Изображение №1 — Интерфейсы на Dprofile

Для начала я разложила сущности, которыми мы оперируем:

— Город (условно, вообще это единица географии, так как может быть область, например, или Вся Россия)

— Период доступа к городу

— Телеканал

— Период доступа к телеканалу

— Общий период доступа к данным (ко всем данным)

Далее определила связи между ними — телеканалы принадлежат конкретным городам, а не наоборот.
Минимальная стабильная (относительно телеканала) единица, от которой стоит отталкиваться, —
город.

Логика построения

В задачах, к которым страшно подступиться, я зачастую применяю способ «от противного»: смоделировала реальный сценарий запроса клиента, чтобы думать не из пустоты, а отталкиваться от чего-то. Получилось примерно так:

«Мне нужен доступ к данным на год, а за год я хочу в первом квартале иметь доступ к городу А, во втором квартале — к городу Б, а все второе полугодие — вся Россия, кроме города Н. При этом в каждом из этих городов мне будет доступен Канал-1 (всегда), а во втором квартале еще и канал-2 на один месяц. Во второй половине года я не хочу видеть данные по каналу-3 ни в одном городе.».

🤡 🤡 🤡 Фух! Стало намного легче, правда?

Разбор о задаче и логику построения интерфейса я расписала очень подробно — настолько, что ChatGPT предложил «дать людям выдохнуть» и «хватит их душить». Поэтому в этом кейсе — супер-короткая версия.

P.S. у меня есть исходный текст описания на конкретном примере с картинками, если вдруг интересно, могу дать почитать...🤡

В общем, моделирование «от противного» помогло мне вывести следующие утверждения:
— Нужно мочь «выколоть» период, город или телеканал из понятия «Все» (будет «Все*» – читай «Все, кроме упомянутых отдельно»).
— Нужно в принципе понятие «Все»: телеканалы, данные и города.
— Нужно мочь ссылаться на периоды доступа к данным и к городу, чтобы не дублировать данные для периодов доступа (цеплять данные, как компоненты и инстансы в фигме, чтобы менять только период доступа, например, а все, кто ссылается на него, применяли уже новые значения).

Как в интерфейсе

Конструктор доступов — Изображение №2 — Интерфейсы на Dprofile

В основе решения — редактируемая таблица с четырьмя колонками.
Каждая строка, начинающаяся с города, — это
одно условие.
Такой подход помогает логично группировать данные: один город — одно условие, внутри него несколько периодов, внутри периодов – телеканалы, у каждого свои пункты условий.

Чтобы охватить базовые функции, я добавила:

🎈Кнопку «Создать условие» — для добавления нового города;

🎈Кнопку «Создать несколько» — если нужно выдать доступ сразу для нескольких городов;

🎈Удаление пунктов и условий: крестики против каждой строки убирают отдельный телеканал, а удаление последнего пункта стирает и всё условие. При этом предусмотрен способ удалить всё условие сразу — без бесконечных кликов (чекбокс выделяет все условие целиком).

🎈Плюсики для добавления пунктов — ховер на период географии, телеканал и период телеканала (те сущности, которых может быть несколько).

Конструктор доступов — Изображение №3 — Интерфейсы на Dprofile
Конструктор доступов — Изображение №4 — Интерфейсы на Dprofile

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

В итоге получился интерфейс, где можно гибко управлять доступами, не теряя структуру и наглядность.

Оценить

Добавить в коллекции...

От автора