Comments 13
Это же наша модель, можно ей сразу напрямую задать такую же форму
А для просмотра/редактирования только своих записей этот подход годится? Я реализовывал через создание ещё одной админки, в которой перезначался queryset и т. п.
Не очень понял как определить кому давать права, а кому нет на эту прокси-модель
не понял как модель ArticleEditProxy привязана к модели Article. может надо применить наследование?
У класса admin.ModelAdmin помимо readonly_fields есть еще метод
ModelAdmin.get_readonly_fields(self, request, obj=None)
По умолчанию он возвращает self.readonly_fields, но его можно переопределить.
Это даст даже большую гибкость — например если для статьи добавить поле author, то его можно сравнивать с request.user. Свою статью можно редактировать полностью, а для чужих только теги.
Если Obj is None — значит пользователь создает новый объект
ModelAdmin.get_readonly_fields(self, request, obj=None)
По умолчанию он возвращает self.readonly_fields, но его можно переопределить.
Это даст даже большую гибкость — например если для статьи добавить поле author, то его можно сравнивать с request.user. Свою статью можно редактировать полностью, а для чужих только теги.
Если Obj is None — значит пользователь создает новый объект
> Для любой модели любого приложения вы можете разрешить пользователю три действия: добавлять новые объекты, редактировать и удалять существующие объекты.
Здесь, скорее, нужно говорить о том, что три права создаются по умолчанию. В Meta::permissions модели можно задать любой набор прав и на одно из них завязать ограниченное редактирование.
Здесь, скорее, нужно говорить о том, что три права создаются по умолчанию. В Meta::permissions модели можно задать любой набор прав и на одно из них завязать ограниченное редактирование.
Sign up to leave a comment.
Ограничиваем интерфейс редактирования с помощью прокси-моделей