Слушай, ну зачем ты в оскорбления скатился? Интересная ж тема, с удовольствием ваши рассуждения читал...

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

Добрый день, прошу совета по "допиливанию" админки, вопрос скорее "хорошего тона"...
Есть масса моделей, News - просто пример для иллюстрации, для каждой прописан ModelAdmin (https://pastebin.com/UjAgmQN7) В пасте - только то, что касается вопроса, вроде, все лишнее убрал...
Изначально прописал наборы полей в свойствах класса (list_display, list_filter, list_editable)
Появилась необходимость разделить наборы полей для обычных пользователей и superuser.
Начал прописывать методы get_list_filter и прочие. Для большинства свойств есть аналогичные методы:
list_display - get_list_display и т.д. А вот для list_editable, как я понял, нет...
В результате наткнулся на то, что при указании поля в свойстве list_editable ругается на то, что поле отсутствует в list_display (его я перенес в метод)...
В итоге прописал list_display и в свойстве и в методе. То есть, то, что для всех, прописано в свойстве, а метод только изменяет его.
Вопрос - как правильнее поступать в таких случаях - переносить всю логику в метод или писать и свойство и метод?

Добрый день, прошу совета по "допиливанию" админки, вопрос скорее "хорошего тона"...
Есть масса моделей, News - просто пример для иллюстрации, для каждой прописан ModelAdmin (https://pastebin.com/UjAgmQN7) В пасте - только то, что касается вопроса, вроде, все лишнее убрал...
Изначально прописал наборы полей в свойствах класса (list_display, list_filter, list_editable)
Появилась необходимость разделить наборы полей для обычных пользователей и superuser.
Начал прописывать методы get_list_filter и прочие. Для большинства свойств есть аналогичные методы:
list_display - get_list_display и т.д. А вот для list_editable, как я понял, нет...
В результате наткнулся на то, что при указании поля в свойстве list_editable ругается на то, что поле отсутствует в list_display (его я перенес в метод)...
В итоге прописал list_display и в свойстве и в методе. То есть, то, что для всех, прописано в свойстве, а метод только изменяет его.
Вопрос - как правильнее поступать в таких случаях - переносить всю логику в метод или писать и свойство и метод?

Добрый день, прошу совета по "допиливанию" админки, вопрос скорее "хорошего тона"...
Есть масса моделей, News - просто пример для иллюстрации, для каждой прописан ModelAdmin (https://pastebin.com/UjAgmQN7) В пасте - только то, что касается вопроса, вроде, все лишнее убрал...
Изначально прописал наборы полей в свойствах класса (list_display, list_filter, list_editable)
Появилась необходимость разделить наборы полей для обычных пользователей и superuser.
Начал прописывать методы get_list_filter и прочие. Для большинства свойств есть аналогичные методы:
list_display - get_list_display и т.д. А вот для list_editable, как я понял, нет...
В результате наткнулся на то, что при указании поля в свойстве list_editable ругается на то, что поле отсутствует в list_display (его я перенес в метод)...
В итоге прописал list_display и в свойстве и в методе. То есть, то, что для всех, прописано в свойстве, а метод только изменяет его.
Вопрос - как правильнее поступать в таких случаях - переносить всю логику в метод или писать и свойство и метод?

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

Почему ты не хочешь создать различные отображения для стаффа и супер юзеров?

Что в данном контексте "отображения"? Вьюхи? Так я вообще стандартную админку настраиваю...

Как вариант, можно создать прокси модель, в админке указать ей необходимые поля и т.д., а доступ (для админки стандартной модели и для админки прокси модели) выдавать стандартными средствами джанги

Например гет форм по юзеру переопределить

Так... Это касается списка в админке.

Ну ты ведь отображаешь форму изменения объекта, или что?

до скоростей сравнимых с Go?

список, ему просто отфильтровать список объектов по автору/роли нужно, можно например менеджер кастомный написать и подсовывать его в админке, но скорее всего есть элегантней решение.

А, фильтры переписать? Из реквест параметров тогда просто берешь значение и по нему фильтруешь

А, фильтры переписать? Из реквест параметров тогда просто берешь значение и по нему фильтруешь

Хмм... А я решаю НЕ через стандартные средства? Вроде, https://docs.djangoproject.com/en/3.1/ref/contrib/admin/

Вот пример того о чем я говорю, надеюсь станет понятнее :)

а уже на сами MainModelAdmin и MainModelProxyAdmin права раздаешь стандартными средствами джанги

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