Смена роли и удаление пользователя

Добавление роли пользователя. Установка роли по умолчанию при регистрации и команда смены роли администратором. Команда удаления неактивного пользователя.

Скрытый контент
Комментарии (20)
Arunas
2020-02-14 07:27

Спасибо. Очень хорошо.

Ответить
Bondarenko Alexandr
2020-02-14 21:49

Спасибо, Дмитрий! Интересен такой момент: вы неоднократно упоминали о подходе Test First. При разработке задачи, к примеру, создания эндпойнта изменения пароля пользователя, на ваш взгляд, следует вначале разработать сценарии взаимодействия с этим эндпойнтом в тестах, а уж затем разработать модульные тесты для проверки метода changePassword у агрегата пользователя, или наоборот, разработать модульные тесты для changePassword, реализовать код для прохождения этих тестов, а уж затем разрабатывать тесты для взаимодействия с эндпойнтом изменения пароля? Или, может быть, какой-то третий вариант?

Ответить
Дмитрий Елисеев
2020-02-20 13:01

Всегда лучше делать так, как будет удобнее.

Если уже есть полные требования к эндпойнту со стороны заказчика, то их можно сразу описать в приёмочных или функциональных тестах и пока эти невыполняющиеся тесты пометить игнорируемыми. А потом реализовать всё в коде, чтобы они прошли.

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

Ответить
Сарибжанов Ильдар
2020-02-15 05:58

Спасибо за урок. У меня вопрос не имеющий отношения к программированию =) Согласно GDPR, пользователь должен иметь возможность удалять данные о себе целиком с сервиса. И как тогда решать проблему удаления? Нам не нужны висячие транзакции, но и удалить их нельзя. Как это решается у больших мальчиков? =)

Ответить
Bondarenko Alexandr
2020-02-15 10:46

Корпоративная тайна)

Ответить
Сарибжанов Ильдар
2020-02-15 17:06

Я, конечно, такой вариант тоже рассматриваю, но потом терморектальные процедуры могут быть прописаны от надзорных органов. Поэтому как-то стрёмно

Ответить
Степанов алексей
2020-02-15 20:05

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

Ответить
BATPYIIIKOB
2020-02-17 13:51

Всё верно - данные обезличиваются, можно сделать через хеш

Ответить
Дмитрий Елисеев
2020-02-20 13:06

Если используются хранилища вроде Kafka без возможности редактировать старые записи, то для слишком чувствительных данных обычно вместо них записывают значения, зашифрованные ключом, который хранится отдельно у каждого пользователя. Потом просто удаляют этот ключ.

Ответить
Максим
2020-02-16 05:27

Дмитрий. Здравствуйте.

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

Здесь волнует такой вопрос, что гео используется во многих сервисах сайта. Получается это гео надо выносить в свой сервис. Так же не понятно как лучше хранить данные: id, координаты, строка. Какие данные можно получать по связям, а какие надо хранить в сущности.

Очень благодарен был бы за рассмотрение этого подхода и работу со сторонними сервисами типа Яндекс, Гугл и др.

А так же загрузку использование своего общего аватара (на подобии gavatar). Но это в принципе понятно. Но тоже интересно.

Ответить
Дмитрий Елисеев
2020-02-20 13:13

Получается это гео надо выносить в свой сервис.

Города и страны можно вынести оидельно, а всем сущностям присваивать только их идентификаторы.

Так же не понятно как лучше хранить данные.

Если нужны просто координаты, то можно записывать в new Coordinate(lat, long)

Какие данные можно получать по связям, а какие надо хранить в сущности.

В доменной сущности нужно хранить только необходимый минимум. Ей хватит только идентификатора.

Связи обычно нужны только для отображения на фронтенде. Поэтому для отображения удобно делать отдельные голые SQL-запросы со всеми нужными нам JOIN-ами. До этого дойдём когда помимо Command начнём делать Query.

Ответить
Максим
2020-02-20 13:19

Благодарю!

Ответить
Sergei
2020-02-28 16:50

Дмитрий, а можно вопрос: вы изменяете историю коммитов или ребейз делаете? У меня гиткракен иногда смещает историю при ваших обновлениях на ориджине. Мне приходится резет делать на мастер/ориджин из-за конфликта с текущей одной единственной веткой :)

Ответить
Дмитрий Елисеев
2020-02-28 22:41

Да, старые коммиты понемногу исправляются интерактивным ребейзом.

Ответить
Sergei
2020-02-29 11:04

Спасибо за ответ. Я думал у меня гиткракен глючит :)

Ответить
Андрей
2020-06-07 18:19

У меня такой вопрос. Допустим, в будущем нам понадобится возможность для каждого товара аукциона настроить видимость по ролям. То есть только пользователи с определенными ролями могут просматривать товар, а с какими именно ролями — настраивается в каждом конкретном товаре. Получается, что где-то в модуле Auction будет свой класс Role или Roles, в котором тоже будут использоваться константы USER и ADMIN.

Как в этом случае поступить? Можно ли вынести эти константы в общий интерфейс, например RoleInterface, и сделать так, чтобы классы в обоих модулях реализовывали этот интерфейс? Или константы в каждом классе должны быть свои? Тогда где их потом сопоставлять?

Если вариант с общим интерфейсом подходит, то где его разместить? Если оставить его в модуле Auth, то получится, что класс одного модуля реализует интерфейс из другого, и модули как бы перестают быть независимыми. Или сделать отдельную папку Interface за пределами модулей и все общие интерфейсы выносить туда?

Ответить
Дмитрий Елисеев
2020-06-08 12:18

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

Ответить
Андрей
2020-06-08 13:01

С ролями действительно получился неудачный пример. Мой вопрос был более общий: насколько корректно, когда классы в разных модулях реализуют какой-то единый интерфейс. Получается, что все-таки так делать не надо? И даже если в разных модулях задействованы одни и те же константы, то они всё равно должны быть у каждого модуля свои. А снаружи уже всё это сопоставляем. Верно?

Ответить
Дмитрий Елисеев
2020-06-08 17:25

Если это просто общий код, то спокойно его используем вроде нашего Flusher из корня. Если же нужна именно логика из другого модуля, то как компромисс можем у одного объявить интерфейс, а снаружи к нему реализовать адаптер. Но корректнее это будет реализовать в виде обмена сообщениями через очередь.

Ответить
Андрей
2020-06-08 17:31

Понял, спасибо

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий