Здравствуйте! Спасибо за интерес к заказу.
Данный заказ на full-stack разработку (front-end, back-end, DB) + подготовка инструкции.
Необходимо реализовать сайт на котором у пользователя будет личный кабинет.
Сайт имеет 5 экранов, 4 из которых вязаны с УЗ, один отображает данные доступные пользователю.

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

Данные пользователя
Данные пользователя связаны один к одному с логином пользователя.
Учетная запись пользователя, помимо данных пользователя должна содержать информацию о нем.
В рамках данного ТЗ УЗ пользователя должна содержать:

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

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

Back-end
Выполнить аутентификацию пользователя. Записать в таблицу аудита факт успешной/не успешной аутентификации.
Разрешать работу с данными только аутентифицированным и авторизированных пользователям.
Предоставлять API для смены пароля.
Записать в таблицу аудита факт попытки смены пароля, если пароль был изменен, то сделать об этом запись в таблицу аудита.
Попытки смены пароля пишутся в аудит если в конфигурации системы включен режим логирования попыток смены пароля.
Предоставлять API для обновления информации о пользователе (телефон).
Записать в таблицу аудита факт смены пользовательских данных.
Предоставляет API для возвращения данных о проектах и задачах (доступных пользователю, см. раздел Database).
Ошибки, возникающие во время работы должны логироваться.

Модуль аудита
Должен быть реализован модуль аудита действий пользователя, в который записывается информация о:

• входе пользователя (login)
• выходе пользователя (если явно нажата кнопка logout)
• смене пароля
• смене личной информации
• …

Back-end предоставляет API создания записи в аудите для front-end. При этом просмотр записей аудита не должен быть доступен в личном кабинете пользователя. Доступ на просмотр есть только у администратора БД.

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

Database
База данных содержит информацию о проектах и задачах.
Для каждого пользователя выделяется свое пространство с данными.
Пространства пользователей не пересекаются между собой, при этом имеют одинаковую структуру.
Необходимо предложить способ реализации (например в MS SQL можно разделять через схемы SCHEMA).
Администратор должен иметь скрипт, который создает пространство с дефолтными таблицами и дефолтным наполнением.
Администратор должен иметь скрипт, которые назначает пользователю созданное пространство данных.
Связь между пользователем и пространством данных многие-ко-многим.

Пример данных
Проект

• Id- идентификатор проекта (строка)
• Name - наименование проекта (строка)

Задачи проекта

• Id - идентификатор задачи проекта (строка)
• ProjectId - идентификатор проекта, к которому относится задача (строка)
• Name - наименование задачи (строка)
• Status - статус задачи (строка). Open, Backlog, InProgress, Closed

Ролевая модель
Требуется предложить способ реализации ролевой модели.
На текущий момент ролевая модель состоит из следующих ролей:

• Менеджер - может добавлять бизнес данный в БД и редактировать их (CRUD данных за рамками данного ТЗ, роль указана для понимания как дальше будет развиваться сайт).
• Пользователь - может делать выборку данных, но не может редактировать их.

Механизм должен предусматривать дальнейшие расширение состава ролей путем доработки системы, но не требуя переработки реализованного функционала.
В системе должен быть справочник операций и групп операций, которые назначаются на роль или отдельного пользователя.
В рамках данного ТЗ пользователям назначается полномочие делать выборку и просмотр данных.

Образ результата
Рабочий модуль личного кабинета на тестовом или вашем хостинге.
Возможность войти на портал под несколькими пользователями:

• новый
• уже выполнявший вход в систему

И выполнить операции, которые описаны выше в ТЗ.
Возможность администратору увидеть кто и когда заходил, когда менял пароль или блок данных о себе.
Исходный код.
Инструкция, в которой должно быть описано:

• список инструментов, БД и модулей необходимых для функционирования реализованных модулей
• как развернуть необходимый инструментарий
• стэк технологий
• описание как деплоить на хостинг
• описание как подключать к будущему функционалу модуль аудита
• описание как подключать к будущему функционалу модуль логгирования
• описание как администратору заводить пользователей пакетом до 100 аккаунтов, каждому создается шаблонное пространство бизнес данных и базовыми полномочиями (см. раздел Database).
• описание как администратору завести пользователей, с указанием доступа к пространствам ранее созданных пользователей, по одному или пакетом для одного из пространств.

Мои ожидания по коммуникациям

1. Предложите пожалуйста вариант решения + стэк на котором будет реализовано.
2. Оцените трудоемкость реализации по модулям
3. Опишите как планируете реализовывать модуль, что это будет: использование готовых решений, нативные функции инструмента, код
4. Стоимость часа/всего проекта.

Не стесняйтесь задавать вопросы по ТЗ, старался описать детально. Но все равно нам с вами важно будет выровняться по образу результата.

P.S. Макеты Figma прикрепил, но считаю что макеты в рамках текущего ТЗ это вторично, для меня важна реализация технической части, удобство в механизме отслеживания активностей пользователей и контроле доступов.