morozovcookie / bank-10205 Goto Github PK

Сериализатор аккаунта возвращает такое:

{
    "rate": 1.0,
    "user": {
        "id": 2,
        "username": "Andrey",
        "first_name": "",
        "last_name": "",
        "is_superuser": false,
        "link": "http://127.0.0.1:8000/api/users/2/"
    }
},

Хорошо бы содержимое объекта user вывести на уровень rate:

{
    "rate": 1.0,
    "id": 2,
    "username": "Andrey",
    "first_name": "",
    "last_name": "",
    "is_superuser": false,
    "link": "http://127.0.0.1:8000/api/users/2/"
}

API: POST /api/events

принимать поле "participants" со списком участников в виде:

{ 
  "parts": 0,
  "account": 0
}

Где account - pk участника; parts - доля участия

По идее, есть транзакции списания и пополнения. Каждому виду транзакции соответствует своё отображение:
• списание - красный фон и стрелочка вниз
• пополнение - зелёный фон и стрелочка вверх

Задаем через query_params условия фильтрации. Понадобится для того, что бы показать события в которых участвует юзер.
Какая-то фильтрация встроена в rest_framework. Плюс подглядел прикольное решение, как круто парсить query_params.

Другими словами - закрытие его. После этого запретить любые изменения над событием.
Открыть его может только тот, кто закрыл или админ.
Нужно, что бы отправлять события в историю, когда оно полностью оплачено и список участников утвержден.

Нужно, что бы событие имело свои "фоточки" - чеки, фотоотчеты, селфи еды и т.п.
front - EventBuilder
api - сериализация файлов
back - модель Event

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

Фильтр public/private

account.rate should be used only in celebrates and birthdays.

When I create superuser by django, I create row only in "auth_user" table. But user api works with accounts table.

Автоматизированная оплата по событиям. Желательно проектировать как опциональную фичу, что бы юзер(по желанию) сам указывал за какие события он заплатил.

Видимо это билдер.
Прикрепление юзера к событию как участника. Указываем линк на аккаунт, и долю(они же части) участия. У модели Event есть метод add_participants, который принимает хеш-мап(участник -> доля).

Необходимо учитывать изменения долга участников, когда появляется/уходит участник

Как это делать? Постранично, динамически или как-то иначе

При клике на строку события, разворачивать список участников: делать это доп.запросом(реакт закеширует). Там показывать данные участника: имя, долг и еще что-нибудь.

Когда 1 из участников покидает событие, остальные делят его долг - создаются соответствующие транзакции. Однако не понятно откуда взялись эти транзакции, в них информация только о самом действии: кто, сколько, куда и тип - diff.
Нужно добавить информацию о произошедшем: "участник 100500 выбыл". Тогда будет понятно откуда появился новый долг.

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

GET /api/events/:id/participants

вернет список участников, в виде массива объектов: {rate, account}, где rate - доля участия, account - ссылка на аккаунт.
Ссылка на аккаунт генерится сериализатором ParticipationSerializer.
Вот я и думаю: стучать с фронта на получение списка участников(в аккордеоне событий) и получать вместо инфы линк не круто. Одна и без линка тоже не очень. Какой минимум инфы нам нужен?
Имя, доля, долг по событию... еще?

Уход из события влечет перераспределение суммарного долга уходящих между оставшимися.

Для этого должны быть реализованы шаблоны.
Создаем событие из шаблона: определенные участники + их доли; цена; видимость(private/public).

нужен сборщик JSX(react) кода в обычный JS, что бы у пользователя не болтался в зависимостях browser.min.js и прочие транспайлеры.
Однако главной необходимостью является возможность разделить по файлам компоненты, архитектурные решение(если такие появятся) и т.д.
В Code Style React'а указано, что следует разделять компоненты так, что бы в одном файле был лишь один компонент.

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

1. почему не стоит сильно интегрироваться со statifiles
2. webpack+react+hot-loader

Почему именно они - интуиция.

В другом проекте уже использую связку pipeline + browserify + bower.
В принципе получилось сносно: запустив сервер, меняю компонент и в браузере, после F5, видны изменения.
Хочется просто видеть различия инструментов.

• Разделение на версии admin multiusers
• Ввод наличных
• Вывод наличных
• Создание событий
• Расчет долгов
• Шаблоны(участие по умолчанию и прочее)

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

Механизм создания связки участника и события

Страница отображения списка пользователей.
Наверно простая таблица, аналогичная списку событий, с той разницей, что нет аккордеона.
Когда решится #6, добавим ссылки на detail view пользователя.

Пока что событие не имеет в интерфейсе такой метод, как pay. Поэтому появляется вопрос:
Нужен ли кейс оплаты сейчас кусок и потом кусок? В данный момент это возможно, но повлечет создание diff-транзакций, которые будут применены и на самого себя.

Я купил пиццу. Логирую в банк: сожрал кусок. Через некоторое время: дожрал остальные куски. В итоге будут 3 транзакции:

• с одним куском (ок)
• с остальными кусками (ок)
• diff - ???

diff появляется потому что общее количество частей сразу не указано.
Более того, при логировании придется вызывать метод add_participants, когда по смыслу мы просто оплачиваем еще куски.

Поэтому возможны несколько решений:

• расширять API класса Event
• создавать CompositeEvent и в нем сразу указывать количество частей
• оставить как есть

Отображение данных по конкретному пользователю. Ололо его, ололо.

На данной странице нужно показывать данные пользователя(аккаунта) и все связанные с ним события и транзакции. Стоит это дело как-то показать структурно одним целым, а не двумя списками, что бы не распылять внимания; к тому же они связаны ололо как.

Отрисовать ту таблицу, что видна банкиру в Excel. Такое представление будет сразу знакомым и в тоже время общим взглядом на состояние банка.
Только как READ.