Сергей Тихонов

Правильно - через makemigrations с добавлением ума. Совсем правильно - как в статье на хабре.

Когда Вы нажимаете кнопку "ОК" на форме в окне браузера, выполняется HTTP-запрос по указанному в форме action с указанным методом. См. HTTP.
Данные формы в зависимости от того, какой метод и тип контента используются, передаются в разных частях этого запроса в разных форматах. См. HTTP/POST
Эти данные попадают в бекенд Django а там маршрутизируются в зависимости от списка маршрутов во view. См. про представления в Django.
Для того, чтобы упростить работу с формами, в Django сделали кучу вещей, облегчающих разбор, валидацию и обработку данных формы. См. работу с формами в Django.

В общем, читать Вам не перечитать.

django-reversion

https://django-select2.readthedocs.io/en/latest/ex...
По примеру видно, что есть что.
search_fields - поля модели, по которым искать вводимый текст
dependent_fields - ключи - название поля формы, триггерящего пересчет, значения - названия поля модели для фильтрации.

Определять по User-Agent кто пришел - ПК или мобилка и рендерить разный HTML.

Это на фронтенде делается, например с помощью django-select2

https://www.postgresql.org/docs/10/static/ddl-part...

Since primary keys are not supported on partitioned tables, foreign keys referencing partitioned tables are not supported, nor are foreign key references from a partitioned table to some other table.

Похоже, FK на партиционированную таблицу не поддерживаются. Можно вручную дропнуть constraint и аккуратно следить за целостностью БД.

Celery позволяет запускать произвольный код в другом процессе.

import django
django.setup() 

@app.task
def do_something():
    pass

Собственно всё, что надо чтобы начать использовать celery. Про настройку хорошо написано в документации.

inlineformset_factory вызывается с extra=1, поэтому formset считает, что передана ровно одна запись. При добавлении нескольких строк надо инкрементировать счетчик из management-формы.

`new` - локальная переменная view, она не попадает в объект p
p.new = True

Для видеочатов от сервера требуется:
* передавать громадные объемы данных (по сравнению с HTML)
* с минимальной задержкой
Поэтому серверная часть - это дикий хардкор.
Или второй вариант, когда соединение устанавливается между участниками напрямую (P2P), и вся дичь серверной части переносится на JS, в плане обработки сетевых ошибок, ошибок кодеков и вот этой всей P2P.
На хабре есть съевшие собаку ребята, у них есть бесплатный уровень использования SDK.

А Django действительно пригодится, регистрацию делать, комнаты-пользователи-вот-это-всё.

У Django-форм есть методы clean_"fieldname", которые проверяют корректность отдельных полей. Метод clean проверяет как эти поля друг с другом сочитаются, поэтому ошибки из него и формируются как non_field_errors (т.е. сами значения корректные - февраль, 31 число - но вместе не сочитаются).
Можно попробовать бросить ValidationError в методе clean_amount.

City.objects.filter(id__in=[i.city.id for i in FlyFromCity.objects.all()])

City.objects.filter(id__in=FlyFromCity.objects.values_list('city_id', flat=True))

Два queryset выше эквиволентны, хотя и генерируют разные SQL. Второй лучше тем, что на момент конструирования он не требует получения всех городов из FlyFromCity. По-идее вопрос с миграциями после этого решится (нет запросов при импорте модуля - нет проблем с миграциями)

Если "сторонний сервис" - это какая-нибудь социальная сеть, то для нее должно быть много документации. Ключевое слово - OAuth.
Если "сторонний сервис" под собственным контролем, то опять же Oauth (надо пилить на обоих сервисах) или другие способы. Ключевики: SSO - Single Sign-On, CAS - Central Authentication Service.