Создать фронт приложения Товары, предварительно изучив гайд, а также то, как это уже реализовано в Пользователях

(аналогично #21)

Аналогично #3, но для таблицы contracts:

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

Аналогично #3, но для таблицы contracts_item_sets:

Создать фронт приложения Договоры, предварительно изучив гайд, а также то, как это уже реализовано в Пользователях

(аналогично #21)

Аналогично #4, но для приложения Товары

• Пофиксить инициализацию Договора
• Добавить проверку уникальности названия номенклатуры в patch

Сделать проверку на ввод отрицательного количества в приложениях:

• Закупки
• Товары
• Продажи

Нам долги в Продажах не нужны!

Аналогично #3, но для таблицы Номенклатуры:

Аналогично #4, но для Номенклатур

Создать фронт приложения Закупки, предварительно изучив гайд, а также то, как это уже реализовано в Пользователях

(аналогично #21)

Создать роуты для приложения Поставщики (выполнить шаги 5-7 отсюда)

Стоит уделить внимание декораторам, они важны и упрощают вам во много жизнь (та же статья).

Также можно смотреть в ресурсы users и делать по аналогии. Нам нужны методы get (для списка), post, get (по id) и patch (по id). Также обратите внимание, что есть штука с permissions, мы их пока не сделали, но это не мешает указывать действия через декораторы.

Аналогично #4, но для приложения Магазины

Создать фронт приложения Номенклатуры

Оно отличается от остальных наличием маппинга с Договорами.

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

Можно сделать что-то вроде таблицы или списка с кнопкой добавления договора

Создать фронт приложения Продажи, предварительно изучив гайд, а также то, как это уже реализовано в Пользователях

Аналогично #3, но для таблицы Продажи:

Аналогично #3, но для таблицы Магазины:

У нас практически пустая таблица полномочий. Если открыть самую первую миграцию, то можно увидеть следующее:

connection.execute(
    sa.insert(t_permissions).values([            
        # Admin           
       {'app_name': 'users', 'action': 'all', 'role_id': 1},            
        # TODO: it needs more permissions
            
        # demo            
        {'app_name': 'users', 'action': 'get', 'role_id': 2},            
        # TODO: it needs more permissions        
    ])
)

У нас приложения больше, чем одно.
Поэтому хорошо было бы добавить полномочий (прям в первой миграции) и сделать даунгред/апгрейд дб
В принципе действия у всех приложений одинаковы (у админа везде all, а у demo веде get), так что тут чисто по-копировать по-вставлять и app_name поменять.

• Создать модель для поставщиков согласно ERD
• Произвести миграции (сгенерировать и апгрейднуть у себя локально, посмотреть, чтобы не было ошибок)

Посмотреть как выглядят модели можно в users/models

В этой задаче необходимо выполнить шаги 1-4 отсюда

ресурсы добавлять не надо!

Аналогично #4, но для приложения Продажи

Во время попытки обновления записи из договоров на фронте (т.е. через приложение, а не запросы) возникает ошибка.

Где и почему:

Ошибку выдает метод get_date из backend\erpsystem\core\utils\dates.py:

В нем с помощью регулярного выражения проверяется соответствие передаваемой даты формату YYYY-MM-DD.

Этот метод в ресурсах договора вызывается в post и в patch, но ошибка возникает только в patch.

Почему так? Потому что при занесении в базу данные находятся в нужном формате YYYY-MM-DD, а вот уже в базе меняются на YYYY-MM-DD HH:mm:ss.SSSZ, потому что в базе у этого поля стоит тип timestamptz (= по сути datetime с timezone, что в модели устанавливается как db.DateTime(timezone=True)). Из-за этого при попытке обновления и возникает ошибка.

Что делать:

1. Первый вариант - поменять в модели формат даты с datetime на date
2. Второй вариант - переписать метод get_date (а соответственно и регулярку 💩 ) с учетом разных форматов данных на входе post и patch

Я бы выбрала первый вариант, потому что использование datetime в данном случае - это оверкил (имхо).

Создать фронт приложения Поставщики, предварительно изучив гайд, а также то, как это уже реализовано в Пользователях

(аналогично #21)

Создать фронт приложения Магазины, предварительно изучив гайд, а также то, как это уже реализовано в Пользователях

(аналогично #21)

Аналогично #4, но для приложения Закупки

Аналогично #4, но для приложения Пользователи

Аналогично #4, но для приложения Номенклатуры

• Добавить добавление договора в конкретную Номенклатуру
• Добавить вывод договоров в get item set

Аналогично #3, но для таблицы Позиции:

Аналогично #4, но для contracts_item_sets

Аналогично #3, но для таблицы Закупки:

Аналогично #4, но для приложения Договоры