#29120 and #29502: autocomplete requires view permission
Dear group, with https://code.djangoproject.com/ticket/29120 it was documented that the change permission of the related model was needed, later https://code.djangoproject.com/ticket/29502 reduced this from change to view permission. However, there is a problem that was well described in this comment: https://code.djangoproject.com/ticket/29502#comment:1 > Good example would be a foreign key to a user. You don't want anyone but > superusers to have access to the user model, but you would have to in this > case. Also mentioned by Carlton at: https://code.djangoproject.com/ticket/29502#comment:1 > There's a slight inconsistency in that no permission to the related model is > needed if you don't use autocomplete. Combined with https://code.djangoproject.com/ticket/29700, which was closed as wontfix, there is a dilemma: Either give anyone who is supposed to work with the parent model view permission to the User model, or forego the autocomplete feature. Would it be possible to remove the permission check from AutocompleteJsonView entirely? Alternatively, another permission „view string representation“? That, imho, would be the clean and proper solution – but also the most elaborate and expensive. Best regards, Carsten -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d7847621-8331-8145-3484-02cfc417ae82%40cafu.de.
rename internal SetPasswordForm.user into "instance" - or add it
Hi Django people,
I'm having trouble using the built-in
django.contrib.auth.forms.PasswordChangeForm (which is a SetPasswordForm
child), called from PasswordChangeView.
I know it is just a kind of example, as there is no actual documentation
of the class, but should be usable stable too in projects, unmodified.
It is mentioned in
https://docs.djangoproject.com/en/4.1/topics/auth/default/#django.contrib.auth.forms.SetPasswordForm
- but never explained, other than "A form that lets a user change their
password without entering the old password." There is no official API.
I use the view as base class for my own HTMX view, and with some other
mixins (that auto-generate some user data) for all the sub views.
For all the other forms in this group (which are ModelViews), "instance"
is the parameter where the form binds it's internal model to.
PasswordChangeForm is a Form (no ModelForm), as it does not make use of
all the ModelForm automagic behaviour and creates 2 password fields
itself. This is all fine. But in a row of forms each accepting
"instance" as data source, this Form steps aside and uses "user" as
argument.
I can see a practicability in it, as it seems to be straightforward if
you use this view alone - but it does not comply to other Django Forms,
and has to be treated as "special" using get_form_kwargs() -> {"user":
...} in views using it.
So my idea is (which may be bad - I could just copy that whole form+view
and reproduce it with "instance" instead of "user", but DRY, ya know) :
What would you say to renaming this "user" parameter into "instance" -
it would make the view compatible to others, especially ModelForms.
Drawbacks: It would break compatibility with every usage that directly
calls the form with the "user" parameter. PasswordChangeView could be
changed, so everyone using *that* would be save. only direct usage would
be affected.
But, would it be a possibility to stay compatible and add a second
(optional) parameter named "instance"? The form could then just decide
in __init__ if (user|instance) is present, and save the one that is
present as self.user.
This would ensure that the view could also call it with "instance", both
would work.
Anything speaking against that?
Best regards,
Christian
--
Dr. Christian González
https://nerdocs.at
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/a9b28310-88fc-912b-fe56-91589f50b7e1%40nerdocs.at.
Technical Board vote on DEP 0012: The Steering Council
Hi all, As it seems discussion on DEP 12 has reached its end, and we received generally positive feedback, I am requesting a vote from the technical board on the following: "Shall we accept DEP 12 and send it to the DSF Board for further approval?" Note that as this is a governance change, it requires a 4/5 majority from the Technical Board, after which it will go to the DSF Board for a vote, and after which it *may* go to the membership for a vote if the two Boards believe that it should (you can read more about these requirements in DEP 10). You can see the text of the DEP here: https://github.com/django/deps/blob/main/draft/0012-steering-council.rst My vote is +1, as I am the author of the DEP and believe it is in the best interests of the longevity of the Django project and sustainable governance. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5d1ba4e9-6eca-41a8-aa4b-64d9ee2310fb%40app.fastmail.com.
