bank-10205's People
Forkers
inteybank-10205's Issues
Отображение списка шаблонов
Раздача долгов участникам
flatten Serialization
Сериализатор аккаунта возвращает такое:
{
"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
Hyperlink for participant in event row
Нужно настройть сериализатор так, что возвращаемый список участников содержал ссылки на станицы пользователей.
Отображение списка событий
Фильтр public/private
Stop using account.rate in regular events
account.rate should be used only in celebrates and birthdays.
Failed createsuperuser
When I create superuser by django, I create row only in "auth_user" table. But user api works with accounts table.
Опциональность оплаты события
Автоматизированная оплата по событиям. Желательно проектировать как опциональную фичу, что бы юзер(по желанию) сам указывал за какие события он заплатил.
Create для событий
Видимо это билдер.
Прикрепление юзера к событию как участника. Указываем линк на аккаунт, и долю(они же части) участия. У модели Event есть метод add_participants, который принимает хеш-мап(участник -> доля).
Добавление участников в активное событие
Необходимо учитывать изменения долга участников, когда появляется/уходит участник
Решить вопрос с отображением списка событий, шаблонов и транзакций
Как это делать? Постранично, динамически или как-то иначе
Accordion view for event participants
При клике на строку события, разворачивать список участников: делать это доп.запросом(реакт закеширует). Там показывать данные участника: имя, долг и еще что-нибудь.
Diff transaction log
Когда 1 из участников покидает событие, остальные делят его долг - создаются соответствующие транзакции. Однако не понятно откуда взялись эти транзакции, в них информация только о самом действии: кто, сколько, куда и тип - diff
.
Нужно добавить информацию о произошедшем: "участник 100500 выбыл". Тогда будет понятно откуда появился новый долг.
Read для событий
Вьюхи событий. Детализированное и для списка.
Учитываем флаг суперюзера и разрешаем редактировать только свои события обычным смертным.
Гиперлинки
GET /api/events/:id/participants
вернет список участников, в виде массива объектов: {rate, account}, где rate - доля участия, account - ссылка на аккаунт.
Ссылка на аккаунт генерится сериализатором ParticipationSerializer.
Вот я и думаю: стучать с фронта на получение списка участников(в аккордеоне событий) и получать вместо инфы линк не круто. Одна и без линка тоже не очень. Какой минимум инфы нам нужен?
Имя, доля, долг по событию... еще?
Удаление участников
Уход из события влечет перераспределение суммарного долга уходящих между оставшимися.
Подключить EventBuilder к созданию шаблонов событий
Для этого должны быть реализованы шаблоны.
Создаем событие из шаблона: определенные участники + их доли; цена; видимость(private/public).
Прикрутить frontent-devtools
нужен сборщик JSX(react) кода в обычный JS, что бы у пользователя не болтался в зависимостях browser.min.js и прочие транспайлеры.
Однако главной необходимостью является возможность разделить по файлам компоненты, архитектурные решение(если такие появятся) и т.д.
В Code Style React'а указано, что следует разделять компоненты так, что бы в одном файле был лишь один компонент.
При всей кажущейся простоте задачи, для данного решения имеется множество подходов и инструментов. Поэтому, как отправную точку, я бы взял статьи:
Почему именно они - интуиция.
В другом проекте уже использую связку pipeline + browserify + bower.
В принципе получилось сносно: запустив сервер, меняю компонент и в браузере, после F5, видны изменения.
Хочется просто видеть различия инструментов.
Milestone. Обсудить курс движения
- Разделение на версии
admin
multiusers
- Ввод наличных
- Вывод наличных
- Создание событий
- Расчет долгов
- Шаблоны(участие по умолчанию и прочее)
Вот собственно список на обсуждение. Последние два я так понимаю одно и тоже, но на всякий разделил.
Предлагаю вычеркивать пункт, когда хотя бы один коммент с описанием будем иметь к нему. Все это для того, что бы мы оба понимали что мы делаем, договаривались об интерфейсе, ну и получали опыт обоих сторон(backend, frontend).
Участие в событии
Механизм создания связки участника и события
User list view
Страница отображения списка пользователей.
Наверно простая таблица, аналогичная списку событий, с той разницей, что нет аккордеона.
Когда решится #6, добавим ссылки на detail view
пользователя.
оплата частей события(кусков пиццы)
Пока что событие не имеет в интерфейсе такой метод, как pay
. Поэтому появляется вопрос:
Нужен ли кейс оплаты сейчас кусок и потом кусок? В данный момент это возможно, но повлечет создание diff-транзакций, которые будут применены и на самого себя.
Я купил пиццу. Логирую в банк: сожрал кусок. Через некоторое время: дожрал остальные куски. В итоге будут 3 транзакции:
- с одним куском (ок)
- с остальными кусками (ок)
- diff - ???
diff появляется потому что общее количество частей сразу не указано.
Более того, при логировании придется вызывать метод add_participants
, когда по смыслу мы просто оплачиваем еще куски.
Поэтому возможны несколько решений:
- расширять API класса
Event
- создавать
CompositeEvent
и в нем сразу указывать количество частей - оставить как есть
При клике на транзакцию переходить к событию, с которым она соотносится
User detail view
Отображение данных по конкретному пользователю. Ололо его, ололо.
На данной странице нужно показывать данные пользователя(аккаунта) и все связанные с ним события и транзакции. Стоит это дело как-то показать структурно одним целым, а не двумя списками, что бы не распылять внимания; к тому же они связаны ололо как.
Excel на главной
Отрисовать ту таблицу, что видна банкиру в Excel. Такое представление будет сразу знакомым и в тоже время общим взглядом на состояние банка.
Только как READ.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.