Best way to contribute to documentation

Django Internals Mentorship
1

Hi, I noticed an error in the docs here: Form fields | Django documentation | Django

My question is: should I open a new issue first and then submit a PR, or is it better to submit a PR right away?

The error btw is this. The docs say the following about disabling a field:

Even if a user tampers with the field’s value submitted to the server, it will be ignored in favor of the value from the form’s initial data.

The above is not true. Data of disabled elements is not sent to server during form submission (just spent a couple of hours before I learned about that). I think what the docs mean is “readonly” but there are not options for that.

2

Hi @MrCordeiro - Welcome aboard! :sailboat:

A ticket might be best in this case to verify, but either way can work.

I don’t think the example you give is in fact wrong. If you hit submit, maybe no value is sent, but an attacker can manually craft the POST data to include the disabled value. The point then is that even if they do this, the submitted value will be ignored.
Hope that makes sense.

Maybe you’ve seen them but here are the Writing Documentation contributing docs — they should help you get fully set up.

Let me know if you need more help getting going. :slightly_smiling_face:

Kind regards, Carlton

1 Like
3

Thanks, @carltongibson!

Well, if the example is correct, then I suppose there is nothing for me to contribute at this point? :sweat_smile:

There must be something wrong in my code then… (I’m rambling now :thinking:) I’m trying to override allauth’s SignupForm to use the email taken from an invitation as soon as I add the disabled option, the view (which is allauths’s which in turn is a FormView) ignores the initial value and stops working.

def init(self, *args, **kwargs):
email = kwargs.pop(‘email’, None)
super().init(*args, **kwargs)
self.fields[‘email’].initial = email
self.fields[‘email’].disabled = True

4

We could find you plenty to contribute on :grinning:

I’m trying to override allauth 's SignupForm to use the email taken from an invitation

Hmmm… really not enough to go on but… I suspect if the field is disabled it just won’t appear in cleaned_data. But then, I come round to agreeing with you that the text is at least a bit weird… Would have to play… :thinking:

To your actual problem, how are you getting the invitation email into the form? Can you override clean_email to set it?

5

Hahah gotcha! :smile:

You’re right: the field doesn’t appear in cleaned_data. My problem itself is fixable: I just use the readonly parameter in the template and it works (dunno if that’s safe, but for an MVP it will do…). I was more concerned if the docs were at fault.

But to your question, I’m using django-invitations. Once it checks if a invite key from the GET request is valid, it adds "account_verified_email" to the session. Then I override the get_form_kwargs:

def get_form_kwargs(self):
    kwargs = super().get_form_kwargs()
    kwargs["email"] = self.request.session.get("account_verified_email")
    return kwargs

Maybe I could override clean_email to get it from the kwargs? My only concern would be to screw up some validation that allauth does.

6

Yeah… can’t say without looking… :slightly_smiling_face: You can but give it a try.