mc
и моделей желательно
Size: a a a
2019 September 09
mc
может, какие-то зависмости где-то
АА
Вот трейс
АА
https://dpaste.de/8MbE это менеджер модели
АА
DT
https://dpaste.de/8MbE это менеджер модели
У тебя account в installed_apps?
АА
У тебя account в installed_apps?
Да
DT
Бишкексий азиямол?
DT
Попробуй перенести User = get_user_model
Из шапки файла в метод класса
Из шапки файла в метод класса
DT
В каждый где используется
АА
Ок, попробую, спасибо)
A
Привет. Я рассматриваю разные подходы к проектированию Rest API. Поделитесь, пожалуйста, что является для вас ключевым фактором в OpenAPI по сравнению с проектированием API в UI(описание через textbox/etc). Спасибо
Анонимный опрос
Проголосовало: 13h
Oscar сильно отличается от обычного цмс?
RK
Гайз, как спроектировать такое:
Есть пользователи, которые могу создавать комнаты. Чтобы присоединиться к комнате нужно заплатить. Но в тот же момент человек может в демо режиме вступить в эту комнату, а потом либо его удаляют по окончанию доступа либо он платит и проходит в комнату на совсем.
https://gist.github.com/Pyc6eH4uk/516d1e9749574c5191a0523fc75426f8
В данный момент я сделал так. Есть модели User, ClassRoom, и Member.
В моделе Member есть поле is_demo, которое по умолчанию None(ни платный, ни демо режим), если режим демо то True, платный режим - False. Как считаете нормально ли так или есть решения получше?
Есть пользователи, которые могу создавать комнаты. Чтобы присоединиться к комнате нужно заплатить. Но в тот же момент человек может в демо режиме вступить в эту комнату, а потом либо его удаляют по окончанию доступа либо он платит и проходит в комнату на совсем.
https://gist.github.com/Pyc6eH4uk/516d1e9749574c5191a0523fc75426f8
В данный момент я сделал так. Есть модели User, ClassRoom, и Member.
В моделе Member есть поле is_demo, которое по умолчанию None(ни платный, ни демо режим), если режим демо то True, платный режим - False. Как считаете нормально ли так или есть решения получше?
D
Гайз, как спроектировать такое:
Есть пользователи, которые могу создавать комнаты. Чтобы присоединиться к комнате нужно заплатить. Но в тот же момент человек может в демо режиме вступить в эту комнату, а потом либо его удаляют по окончанию доступа либо он платит и проходит в комнату на совсем.
https://gist.github.com/Pyc6eH4uk/516d1e9749574c5191a0523fc75426f8
В данный момент я сделал так. Есть модели User, ClassRoom, и Member.
В моделе Member есть поле is_demo, которое по умолчанию None(ни платный, ни демо режим), если режим демо то True, платный режим - False. Как считаете нормально ли так или есть решения получше?
Есть пользователи, которые могу создавать комнаты. Чтобы присоединиться к комнате нужно заплатить. Но в тот же момент человек может в демо режиме вступить в эту комнату, а потом либо его удаляют по окончанию доступа либо он платит и проходит в комнату на совсем.
https://gist.github.com/Pyc6eH4uk/516d1e9749574c5191a0523fc75426f8
В данный момент я сделал так. Есть модели User, ClassRoom, и Member.
В моделе Member есть поле is_demo, которое по умолчанию None(ни платный, ни демо режим), если режим демо то True, платный режим - False. Как считаете нормально ли так или есть решения получше?
Кинки пати какой-то:)
D
Гайз, как спроектировать такое:
Есть пользователи, которые могу создавать комнаты. Чтобы присоединиться к комнате нужно заплатить. Но в тот же момент человек может в демо режиме вступить в эту комнату, а потом либо его удаляют по окончанию доступа либо он платит и проходит в комнату на совсем.
https://gist.github.com/Pyc6eH4uk/516d1e9749574c5191a0523fc75426f8
В данный момент я сделал так. Есть модели User, ClassRoom, и Member.
В моделе Member есть поле is_demo, которое по умолчанию None(ни платный, ни демо режим), если режим демо то True, платный режим - False. Как считаете нормально ли так или есть решения получше?
Есть пользователи, которые могу создавать комнаты. Чтобы присоединиться к комнате нужно заплатить. Но в тот же момент человек может в демо режиме вступить в эту комнату, а потом либо его удаляют по окончанию доступа либо он платит и проходит в комнату на совсем.
https://gist.github.com/Pyc6eH4uk/516d1e9749574c5191a0523fc75426f8
В данный момент я сделал так. Есть модели User, ClassRoom, и Member.
В моделе Member есть поле is_demo, которое по умолчанию None(ни платный, ни демо режим), если режим демо то True, платный режим - False. Как считаете нормально ли так или есть решения получше?
К каждой комнате создаётся объект пэймент терм. Здесь указывается цена и допустим время демо доступа. Дальше к пэймент терм создаётся пэймент, который связывает пользователя и комнату и время . Здесь можно отметить булево поле демо.
🔐
Гайз, как спроектировать такое:
Есть пользователи, которые могу создавать комнаты. Чтобы присоединиться к комнате нужно заплатить. Но в тот же момент человек может в демо режиме вступить в эту комнату, а потом либо его удаляют по окончанию доступа либо он платит и проходит в комнату на совсем.
https://gist.github.com/Pyc6eH4uk/516d1e9749574c5191a0523fc75426f8
В данный момент я сделал так. Есть модели User, ClassRoom, и Member.
В моделе Member есть поле is_demo, которое по умолчанию None(ни платный, ни демо режим), если режим демо то True, платный режим - False. Как считаете нормально ли так или есть решения получше?
Есть пользователи, которые могу создавать комнаты. Чтобы присоединиться к комнате нужно заплатить. Но в тот же момент человек может в демо режиме вступить в эту комнату, а потом либо его удаляют по окончанию доступа либо он платит и проходит в комнату на совсем.
https://gist.github.com/Pyc6eH4uk/516d1e9749574c5191a0523fc75426f8
В данный момент я сделал так. Есть модели User, ClassRoom, и Member.
В моделе Member есть поле is_demo, которое по умолчанию None(ни платный, ни демо режим), если режим демо то True, платный режим - False. Как считаете нормально ли так или есть решения получше?
вроде нормас, потом подрубаешь периодик таск на получение всех демо юзеров у которых к примеру уже доступ gte=7 дней и .delete()