так, ты можешь просто исключить эти поля)

ну и всегда метод save можно переписать)

Я же вроди как это и написал. Или имелось ввиду исключать не на уровне админки?

мне показалось, что ты имеешь ввиду blank=True, я имею ввиду exclude в inline, при это в модели надо добавить null=True

у тебя есть некоторая модель данных, если её можно сломать, сломав админку и только - это плохая архитектура потому что админка берёт на себя слишком много, это не её задача обеспечивать проверку целостности данных

разумеется, из этого не следует, что люди так не делают :-) просто на выходе получаются "макароны" и замена админки на какую-нибудь другую приведёт к багу со структурой, сэкономишь время сейчас, всецело положившись на админку - получишь грабли потом)

ну вообщем-то да. Я думаю, что делать проверку в save() это более ли менее здравая идея... Правда внедрять её уже буду при возникновении проблем с моей моделью

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

да, разумеется, для этого и чатик)

я не сторонник толстых моделей (и переопределения save() ) - это приведёт к сильной зависимости от Django ORM, к более сильной, чем могло бы быть, будь эта логика отдельно в файле services.py

я сторонник тонких вьюшек и моделей и помещения всего кода с бизнес-логикой отдельно в services.py

этот подход гуглится по словам Django API Domains, там не только про это, но и про это тоже

Есть модель Partner. Это что-то вроде физ.лица. У него может быть компания, соответственно связь с моделью Company, которой может и не быть.

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

Я думаю, что самое адекватное в таком случае это ссылка через одно только поле recipient_of_money = ForeignKey(PaymentInfo) с конкретной информацией о плательщике.

Как у физ.лица так и у юр.лица может быть разная платёжная информация PaymentInfo

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

Исходя из всех вышесказанных условий я сделал вывод, что самым оптимальным вариантом, это сделать в PaymentInfo одновременно ссылки на Company и на Partner через ForeignKey(blank=True). А в recipient_of_money выбирать кошелёк, на который отправлять в ручную с помощью django-autocomplete

Небольшое дополнение. Один и тот же Partner может быть как поставщиком, так и клиентом.

в одном из проектов нечто подобное сделано через выделение аккаунта и проверка связи пользователь-аккаунт или организация-аккаунт через check

Всем привет! Вопрос к ветеранам или кто активно работал с удаленной машиной. Проблема вот в чем, настроил удалённую машину, nginx, gunicorn, все работало, после того, как отключился от машины, при повторном подключении: mosh log@IP
Долго думает и выдаёт такую ошибку:
ssh_exchange_identification: Connection closed by remote host

/usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?).
Хочу заметить, что фаилы с конфигурацией на своём пк я не трогал. Вопрос активно гуглил, нашёл такую же проблему, но там сказано, что проблема в самом сервере. У кого какие идеи? За ранее спасибо

Ну то есть идея с двумя полями ForeignKey(blank=True) адекватная в моём случае?

она адекватная с constraint'ами и/или с другими проверками, а если эти проверки запихнуть только в админку - это не очень хорошо)

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