Единственное что я вижу - так это обрезать им досутп к тем полям.

Делаем следующим образом. Создаем нужное количество разнообразных форм, унаследовавшись от базовой. В файле с вьюхами создаем словарь, где ключ - название группы, значение - форма. В самой вьхе пишем что-то типа form = forms_dict[request.user.group]

Готово, у Вас во вьюхе получена специальная форма для определенной группы пользователей

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

Делаем следующим образом. Создаем нужное количество разнообразных форм, унаследовавшись от базовой. В файле с вьюхами создаем словарь, где ключ - название группы, значение - форма. В самой вьхе пишем что-то типа form = forms_dict[request.user.group]

Звучит круто, но это тоже самое что ты и предалгал, только через словарь)

Ну да.

всем добричка!

псс, пацанчик ООП не хочешь ? первая доза бесплатно ;)

Просто это будет работать. И будет хорошо работать. И если групп пользователей не over 9999999, то и кода будет не много. Отдельный файлик, где легко, лаконично и просто можно менять поля каждой из групп

псс, пацанчик ООП не хочешь ? первая доза бесплатно ;)

оо, это можно!

псс, пацанчик ООП не хочешь ? первая доза бесплатно ;)

Фабрику форм типа?

нее пока на текущем варианте нормально

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

Мы же не выводим все формы сразу. А лишь одну.

А чем способ init плох?

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

те смотри если разница в одном поле и одном условии то да вариант с init вполне подходит, я так думаю

но если полей больше и вариантов условий больше то стоит разелать на разные сущности

опять таки избавляет от необходимости передавать лишние данные в форму

А подскажите по поводу комментарией, как правильно сделать? На сайте есть несколько моделей - статья, продукт и тд. К ним нужно прицепить комментарии. Разные таблицы типа комментарии для статьи, комментарии для продукта делать не хочу, хочу чтобы это было в одной таблице. В других фреймворках опять же это решается полиморфными связями. А как это решается в джанго? в прошлый раз мне посоветовали для другой задачи contentTypes - тут это тру решение, или есть лучше?

те смотри если разница в одном поле и одном условии то да вариант с init вполне подходит, я так думаю

Поля два всего

А подскажите по поводу комментарией, как правильно сделать? На сайте есть несколько моделей - статья, продукт и тд. К ним нужно прицепить комментарии. Разные таблицы типа комментарии для статьи, комментарии для продукта делать не хочу, хочу чтобы это было в одной таблице. В других фреймворках опять же это решается полиморфными связями. А как это решается в джанго? в прошлый раз мне посоветовали для другой задачи contentTypes - тут это тру решение, или есть лучше?

content_type да как вариант но я бы делал разные таблицы

content_type да как вариант но я бы делал разные таблицы

почему разные?

если на сайте будет за десяток типов материалов, это же будет неудобно пользователю в кабинете показывать его комментарии

или не?

content_type да как вариант но я бы делал разные таблицы

я же правильно понимаю что content_type это аналог полиморфных связей в джанге?

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

для такого случая есть классное решение в sqlalchemy

но в джанго такого вроде нет

я же правильно понимаю что content_type это аналог полиморфных связей в джанге?

не совсем , если я правильно понял

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

тоесть на каждый тип материала это еще и своя модель комментариев?

class BookSubmitForm(ModelForm): def __init__(self, *args, **kwargs): self.request = kwargs.pop("request") super(BookSubmitForm, self).__init__(*args, **kwargs) Как один из Вариантов, только проблематика заключается в том, зачем здеся super()

или общая модель, пока не понадобится для какого-то типа уникальное поле?

class BookSubmitForm(ModelForm): def __init__(self, *args, **kwargs): self.request = kwargs.pop("request") super(BookSubmitForm, self).__init__(*args, **kwargs) Как один из Вариантов, только проблематика заключается в том, зачем здеся super()

а чем тебе super не нравится ?

тоесть на каждый тип материала это еще и своя модель комментариев?

да я за вариант где для каждой типа материала отдельная таблица коментариев

а чем тебе super не нравится ?

Я так понимаю что super() занимается наследованием родительского класса, но он (def) уже жде в классе

да я за вариант где для каждой типа материала отдельная таблица коментариев

понял, спасибо, нужно обдумать

Я так понимаю что super() занимается наследованием родительского класса, но он (def) уже жде в классе

это вызов родительского конструктора

Зачем ему его вызывать вданной конструкции?

Зачем ему его вызывать вданной конструкции?

ЧТобы использовать метод init родителя. Если перейти в него, можно увидеть, что он имеет свою логику. Переопределив его, мы полностью стираем эту логику и заменяем нашей. Но, когда мы делаем подобным образом мы не заменяем, а дополняем метод родителя

super дополняет?

super дополняет?

Не совсем. Super() - обращение к родителю. Super().init() к методу init родителя

У меня достаточно странный вопрос есть... Точнее, я не совсем понимаю как его правильно сформулировать. В общем я работаю с вебсокетами в джанге через channels (притом, что я не до конца понимаю механизм функционирования вебсокетов в channels, поэтому что-то тут я уже гарантированно сделал неправильно). Также у меня есть приложение, которое запущено в папке одного из приложений джанги (речь о телеграм-боте), но которое фактически работает отдельно от неё (поместил бота в ту же папку чтобы было проще общими моделями пользоваться). Так вот: грубо говоря нужно чтобы сообщения, приходящие боту, пересылались в джанговское приложение (то бишь на сайт). И вот как это сделать я не совсем понимаю. Будет здорово, если подскажете.

и получается, у нас self.init + super().init

как-то так.

да я за вариант где для каждой типа материала отдельная таблица коментариев

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

А, ну, тоже самое Вы и говорите, ага

Тогда плюсую. Вытащить комментарии отдельно - лучшее, что можно придумать, на мой взгляд

Потом уже усложнять структуру, по мере надобности. Вводить ответы и т.п.

https://dpaste.de/yizR Вот так пытаюсь передать через инит форму, почему то не делает ее рид онли, даже если захожу под группой group. выдает File "C:\Users\sysoev.m\majorpack\personnel\forms.py", line 211, in __init__ self.request = kwargs.pop("request") KeyError: 'request'

Точнее он это выдает когда я делаю submit

Ну, он, дословно, говорит, что не в кваргах request-а

Что странно ведь шаблон по гет запросу

Грузится

Проверяйте содержимое кваргов.

Проверяйте содержимое кваргов.

Он ргается на инстанс теперь

я плохо в ясновидение. На какой инстанс? Где? Код, ошибку.

я плохо в ясновидение. На какой инстанс? Где? Код, ошибку.

https://dpaste.de/yizR

Я сверху кидал

https://dpaste.de/yizR Вот так пытаюсь передать через инит форму, почему то не делает ее рид онли, даже если захожу под группой group. выдает File "C:\Users\sysoev.m\majorpack\personnel\forms.py", line 211, in __init__ self.request = kwargs.pop("request") KeyError: 'request'

.

Ну и где инстанс?

Где ошибка?

В чем ошибка? Ругается на инстанс

инстанс чего, кого, где

И, я может и ошибаюсь, но self.arrival, наверное, так надо.

Да и всё-таки надо super().init() делать, иначе остальные поля у вас не проинициализируются. Да и форма не проинициализируется

инстанс чего, кого, где

Инстанс 15 строка

Инстанс 15 строка

Окей, теперь вижу.

Но ошибку лучше всё равно присылать

Он почему то init инициализирует только при Post

File "C:\Users\sysoev.m\majorpack\personnel\forms.py", line 211, in __init__ self.request = kwargs.pop("request") KeyError: 'request'

Ага, увидел супер

File "C:\Users\sysoev.m\majorpack\personnel\forms.py", line 211, in __init__ self.request = kwargs.pop("request") KeyError: 'request'

Вы издеваетесь.

Вам пишут, KEY_ERROR - нет такого ключа в кваргах

Вам пишут, KEY_ERROR - нет такого ключа в кваргах

instance=Plan.objects.get(pk=pk), request=request

а) запустите дебаг и посмотрите, что у вас в кваргах. б) напишите print(kwargs) и посмотрите, что у Вас в кваргах

Если Вам пишут KeyError, это не издевка компилятора - это отсутствие ключа.

>б) напишите print(kwargs) и посмотрите, что у Вас в кваргах >Он ргается на инстанс теперь

Ошибку, пожалуйста

не просто "Ругается"

а прям вот, что пишет

а прям вот, что пишет

File "C:\Users\sysoev.m\majorpack\personnel\forms.py", line 211, in __init__ print(**kwargs) TypeError: 'instance' is an invalid keyword argument for this function

Вопросы?

Почему инвалид?

Потому что его там нет.

form = PrimaryForm(instance=Plan.objects.get(pk=pk), request=request) return render(request, self.template_name, {'form': form, 'pk': pk, 'somequery': somequery}) Тоесть тут он ничего в кварги не отправляет?

Ой, туплю я

и вы)

File "C:\Users\sysoev.m\majorpack\personnel\forms.py", line 211, in __init__ print(**kwargs) TypeError: 'instance' is an invalid keyword argument for this function

Передайте без звездочек

он думает, что instance - параметр функции.

Когда мы ставим ** мы передаем словарь как аргумент-значение, на не просто словарь.

Поправьте, если не так.

{'instance': <Plan: Точка 1 Точка 2>, 'request': <WSGIRequest: GET '/personnel/primary/28'>}

Он передает не то, надо навреное requset.user

Скиньте, пожалуйста, Middleware из Settings.py, прям с названием списка

MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ]

попробуйте поменять порядок, поставив AuthenticationMiddleware перед Session. Если верить гугулу, это исправит ошибку с получением user-a. А может и не исправит, глянем. Также, надо понять, почему в кваргах не вытаскивается request. Попробуйте просто обратиться к нему через print(kwargs['request']), для начала. Ну и сразу добавьте, print(kwargs['request'].user), на проверку.

попробуйте поменять порядок, поставив AuthenticationMiddleware перед Session. Если верить гугулу, это исправит ошибку с получением user-a. А может и не исправит, глянем. Также, надо понять, почему в кваргах не вытаскивается request. Попробуйте просто обратиться к нему через print(kwargs['request']), для начала. Ну и сразу добавьте, print(kwargs['request'].user), на проверку.

Я точно не понял как, но я смог вытянуть группу, потому что именно она мне и нужна была. Дальше стоит вопрос, почему форма поля не становится той, которую я задаю в init def __init__(self, *args, **kwargs): print(kwargs) grop = kwargs.pop('usar') super(PrimaryForm, self).__init__(*args, **kwargs) if grop == "log-surgut": arrival = DateTimeField(widget=forms.TextInput(attrs={'readonly': 'readonly'}), required=False)