bzalyaliev / requests Goto Github PK

Maybe render

Описание

Необходимо добавить liquibase в сэтап приложения

Требования

1. В classpath приложения содержатся liquibase ресурсы, которые будут использованы в runtime для миграции базы данных
2. Стартуя, приложение "накатывает" (liquibase update) изменения на целевую базу данных, см https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.data-initialization.migration-tool.liquibase
3. Базовый сэт изменений включает:
   • создание базы данных (схемы), вроде мы это вручную делаем сейчас
   • создание таблицы. заменяем hibernate auto-ddl update на none, используя liquibase, то есть выключаем первый вообще - все изменения базы данных в будущем должны идти через liquibase
4. Проект содержчик changesets для:

• выполнение всех команд из файла schema.sql
• insert двух ролей
• insert одного базового admin пользователя

Критерий:

1. Тесты должны проходит (на пункт 4.1).
2. Локально проверить.

Описание

Реализовать сортировку записей в таблице Все запросы согласно правилу:

• выше всего заявки со статусом Generated;
• далее заявки со статусом In work;
• далее заявки со статусами Done, Cancelled, Rejected в порядковых номерах.

Все юзеры создаются администратором (мной) через liquibase.

Критерии проверки:

1. POST запрос на определенный эндпоинт авторизует пользователя:
   https://developer.mozilla.org/ru/docs/Web/HTTP/Headers/Set-Cookie
   Ожидаем заголовок set-cookie
2. Настраиваем эндпоинты, чтобы они падали с 401, если запрос не аутентифицирован. Вызываем любой эндопинт на сервере, установив куки из первого пункта.
3. Опционально. Авторизация. админу доступны все ресурсы (придумать).

Эндпоинт /login
см. документацию https://docs.spring.io/spring-security/reference/index.html и пример https://github.com/Himal99/SpringBoot-Role-Based-authentication

Требования:

• nginx конфигурация находится в requests-infrastructure репозитории
• репозиторий requests-infrastructure содержит достаточную инструкцию по запуску nginx

Описание

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

Подумать, решить

1. Простой вариант (для старта работы этот вариант подходит):

• две роли - user и admin (c возможностью редактирования заявок).
• вход по паролю.

2. Сложный вариант (для интеграции с другими нашими сервисами, возможно следующий шаг):

• аутентификация с помощью Microsoft Azure AD;
• библиотека msal
  https://docs.microsoft.com/ru-ru/azure/active-directory/develop/msal-overview
  https://docs.microsoft.com/ru-ru/azure/active-directory/develop/reference-v2-libraries
  https://github.com/AzureAD/microsoft-authentication-library-for-java
• сервер аутентификации может написать мой коллега
• нужна схема, как это работает.

Критерии проверки

Шаги

Улучшения

Описание

Для роли Администратор необходимо реализовать возможность изменения некоторых полей заявки.

Делаем после аутентификации с ролями #14

Как это может выглядеть

1. Пользователь авторизуется как администратор.
2. Во вкладке "Все запросы" у каждой заявки появляется кнопка или текст Edit.
3. При нажатии на Edit открывается форма для редактирования (как и при создании новой записи), в которой есть возможность изменить:

• Статус (из выпадающего списка).
• Тип (из выпадающего списка).
• Масса.
• Срок завершения.

4. Возможно, у это формы должна быть кнопка Изменить (подумать, как лучше сделать).

Реализация

Скоуп изменений - фронтенд, после завершения истории аутентификации нужно смотреть откуда взять роль на фронте

Описание

Сделать цветовое оформление заявок согласно правилу:

• Generated - серый
• In work - жёлтый
• Done - зелёный
• Сancelled - оранжевый
• Rejected - красный

Add swagger documentation for API-methods

Описание:

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

С целью уменьшить риски потери данных с удалением контейнера необходимо использовать файловую систему сервера для базы данных

Критерии проверки

1. При выключенном контейнере PostgreSQL база данных существует на сервере в определенной папке
2. Если удалить контейнер, то база данных доступно на сервере в определенной папке

Шаги

1. Добавить volume mounting для описание PostgreSQL контейнера в docker-compose файл

Улучшения

Подумать, куда и с какой периодичностью дампить базу данных

How to run requests application

First way.

./mvnw clean package

./mvnw jib:dockerBuild -Djib.to.image=requests -Djib.to.tags=latest

docker network create --driver bridge network_name

docker run --name my_postgres --network=network_name -e POSTGRES_PASSWORD=my_password -d postgres:13

sudo docker exec -it my_postgres psql -U postgres

CREATE DATABASE requests;

docker run —name requests_application p 8080:8080 --network=network_name -e SPRING_DATASOURCE_URL=jdbc:postgresql://my_postgres:5432/requests requests:latest

As result 2 docker containers

Also, to add instruction how to run application by docker compose!

Описание

Добавить выпадающий список инициаторов заявки.
Список есть в наличии.

Таска выполняется после добавления liquibase

Требования

1. Liquibase содержит changeset с созданием новой таблицы: INITIATOR @bzalyaliev ?
2. Таблица нормализована - REQUESTS ссылается на INITIATOR по айди
3. Сервис имеет отдельный эндпоинт: /api/requests/intiator который возвращает всех инициаторов в виде JSON массива (тут можно подумать про кэш клиентский, опционально. Можно отправлять такой заголовок, что браузер поймет, что можно ответ закэшировать - это рационально)

1. Нужен ли docker-compose file
2. Какая инструкция для запуска контейнера с базой данных?
   docker run -d --name my_postgres -v my_dbdata:/var/lib/postgresql/data -p 54320:5432 -e POSTGRES_PASSWORD=my_password postgres:13
   или
   docker run --name my_postgres --network=network_name -e POSTGRES_PASSWORD=my_password -d postgres:13

Добавить страницу на фронт, где пользователь будет вводить свои логин и пароль. JS выполняет пост запрос.

Описание

1. Нужно реализовать функцию отправки админу на почту уведомление, когда приходит новая заявка.

Подумать

1. Если развивать систему нотификаций - то можно будет сделать оповещение заявителя.
2. Нотификация как на почту, так и в таск-трекер, используемый в компании.

Описание

Необходимо реализовать выпадающий список для поля Тип.
Список есть.

Таска выполняется после добавления liquibase

Требования

1. Liquibase содержит changeset с созданием новой таблицы: MATERIAL_TYPE @bzalyaliev ?
2. Таблица нормализована - REQUESTS ссылается на MATERIAL_TYPE по айди
3. Сервис имеет отдельный эндпоинт: /api/requests/types который возвращает все типы в виде JSON массива (тут можно подумать про кэш клиентский, опционально. Можно отправлять такой заголовок, что браузер поймет, что можно ответ закэшировать - это рационально)

Описание

Для улучшения поддержки приложения и возможности кастомизации логирования следует добавить logback конфигурацию приложения, а также логировать входящий запрос и ответ

Требования:

• запрос логирует: url + query
• ответ логирует: статус код
• на сервере сообщения логируются в файлы на хосте, а не внутри контейнера. То есть, директория с логами на сервере должна быть замаунтена в контейнер и приложение пишет в нее
• logback создает новый файл при достижении определенного размера, например: 10 ГБ
• стартуя локально main class spring boot приложения (из айдии), оно пишет логи как всегда в консоль

Как имплементировать:

1. Объявить отдельный профиль prod, который должен быть активирован только на реальном промышленном стенде путем передачи переменной окружения в docker-compose файле: SPRING_PROFILES_ACTIVE = prod
2. Локально приложение стартует без профилей, чтобы писать в консоль

logback-spring.xml
<configuration>
    <springProfile name="prod">
       <!--- тут prod конфигурация - пишем в файл -->
    </springProfile>
    <springProfile name="!prod"> <!-- не прод -->
       <!--- тут test конфигурация logback - пишем в systemout -->
    </springProfile>
</configuration>

3. Для определенний политик создания файлов логов (аля новый файл, каждые 10 гб) смотри свойство rollingPolicy, пример в официальной документации - https://logback.qos.ch/manual/appenders.html - ищи <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
4. Для !prod можно использовать что-то типа, будет зелененьким выделять часть логов:

<configuration>
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <pattern>%d %green([%thread]) %highlight(%level) %logger{50} - %msg%n</pattern>
        </encoder>
    </appender>

    <root level="info">
        <appender-ref ref="console" />
    </root>
</configuration>

5. Обрати внимание, что путь внутри контейнера может отличаться от пути на хосте. Ты можешь добавить свойство logback <file> и посмотреть куда он пишет (скорее всего в ту дирикторию, где jar), например <file>/usr/log скорее всего по абсолютному пути /user/log пишет

Соответственно, docker-compose должен содержать маунтинг внутрь: например, папка на хосте /var/app/requests/log линкуется в /usr/log контейнера

как посмотреть внутрь контейнера:

docker exec -it <container-id> sh
#и ходи там ls / cd

Я не уверен, где jar точно лежит, нужно погуглить, должна быть какая-то директория для случая jib.

Смотри:

1. Configure logback https://docs.spring.io/spring-boot/docs/2.1.8.RELEASE/reference/html/howto-logging.html
2. Add request/response logging https://www.baeldung.com/spring-http-logging

GitHub actions:

1. Discovery + MVP @artemptushkin
2. pipeline @bzalyaliev

Описание

1. Необходимо создать 2 ORM сущности с repository (JPA or CRUD): User, Role
2. Неоходимо мигририровать инструменты накатки изменений базы данных с hibernate ddl-auto на shema.sql и data.sql смотри https://docs.spring.io/spring-boot/docs/1.2.0.M1/reference/html/howto-database-initialization.html#howto-intialize-a-database-using-spring-jdbc

Название таблиц, соответственно: auth_user & auth_role

Структура:

user:

• id (long)
• createdAt (datetime)
• first name
• last name
• email
• login
• role (many to one) -> ссылается на role

role:

• id
• name (admin, user)

Role объекта auth_user связан с таблицей auth_role связью many to one: на 1 роль приходится много юзеров

Требования:

1.1. Невозможно создать юзера, если отсутствует роль в БД
1.2. Невозможно удаление роли, если существует хотябы один юзер ссылающийся на нее
2.1. schema.sql содержит код всех таблиц и сущностей базы данных приложений на SQL диалекте PostgreSQL

Требования зафиксированы тестами, такими же как *RepositoryTest в текущем проекте

Пример и подсказочки

• https://github.com/Himal99/SpringBoot-Role-Based-authentication
  Здесь можно подсмотреть, разница в том, что они создают промеждуточную таблицу через ManyToMany (это автоматически hibernate делает) - мы этого не делаем, должен быть foreign key между auth_user и auth_role и все

• Для отладки, чтобы видеть в тестах что там делает hibernate / jpa:

spring:
  jpa:
    properties:
      hibernate:
        format_sql: true
    show-sql: true

Это должно быть включено только в тестах и никак в продакшен приложении - вспоминаем, как пользоваться spring application properties

• Для отладки, чтобы убедиться, что там наделал hibernate / jpa с базой данных

1. ставим break point в @Test методы - когда уже все запустилось
2. ищем в логах ".port" и там будет порт внешний postgresql testcontainers database
3. создаем как всегда в айдии подключение к базе данных, зная порт
4. КАЖДЫЙ НОВЫЙ ЗАПУСК - НОВЫЙ ПОРТ!
5. обновляем cхему (refresh button), чтобы каждый новый запуск видеть новое состояние

• Картиночки на тему Hibernate / Jpa lifecycle

• https://docs.oracle.com/cd/E16439_01/doc.1013/e13981/img/lifeent30.gif

• https://static.javatpoint.com/hibernatepages/images/hibernate-lifecycle.png

• https://vladmihalcea.com/wp-content/uploads/2014/07/hibernateentitystates1.png

Подумать

1. Отдельный сервис "Analysis base" - для хранения результатов исследований образцов (файлы doc, pdf, txt). С поиском и фильтрацией. При нажатии на файл, его можно посмотреть.
2. Сервис "Расход" (рабочее название) - сервис, где происходит работа после оформления заявки. Коллеги запросили материал определенного типа, далее, если это порошок, то его нужно делать, забирать со склада и так далее.
3. Сервис "Склад" (рабочее название) - приход/уход материала, статистика, текущий статус.