Opened 6 years ago

Closed 6 years ago

Last modified 2 months ago

#11365 closed Uncategorized (fixed)

django.db.models.fields.EmailField max_length should be 254

Reported by: shellsage Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords: email field max_length
Cc: bas@… Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

http://www.eph.co.uk/resources/email-address-length-faq/ points out that the current max_length of 75 on EmailField fields is too short. It should be extended to 254 to comply with standards.

I checked the EmailField form field, and it does not seem to enforce a min_length or max_length by default, even though the min_length is 6 chars, and max_length is 254.

Attachments (1)

emailfield-max_length-r11092.patch (529 bytes) - added by shellsage 6 years ago.
Patch for correct EmailField max_length, against r11092

Download all attachments as: .zip

Change History (8)

Changed 6 years ago by shellsage

Patch for correct EmailField max_length, against r11092

comment:1 Changed 6 years ago by graham_king

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

+1 because 75 chars is too short to store the Facebook proxied email address that their API dishes out.

comment:2 Changed 6 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

Firstly, EmailField accepts a max_length argument, so you can set your email fields to be as long as you like.

Secondly, while I agree that 75 characters isn't strictly standards compliant, it isn't something we can change easily. Changing max_length would be backwards incompatible for every existing installation of Django.

So - when we start having v2.0 discussions, this is one of the backwards incompatible changes will can consider. In the interim, use the max_length argument.

I'm closing this ticket because we don't really have a good way to track 'things we need to do for v2.0'.

comment:3 Changed 6 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

The issue with this is that the EmailField is used by the django auth system, so that is directly affected.

comment:4 Changed 6 years ago by dc

  • Resolution set to wontfix
  • Status changed from reopened to closed

Please don't reopen tickets that have been closed by a core committer. If you disagree with a decision, start a thread on django-developers.

comment:5 Changed 5 years ago by anonymous

  • Cc bas@… added

comment:6 Changed 2 months ago by hheimbuerger

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
  • UI/UX unset

This has actually been implemented on the 1.8 branch: https://github.com/django/django/commit/7fd55c3481a004afb049e15ae3b8c93ce8bf0603

Can we mark this ticket as resolved now? It's confusing to see it as marked 'wontfix' when the title actually reflects the current state of the source.

Note: I didn't touch or mean to affect any of the flags Trac just modified…

Last edited 2 months ago by hheimbuerger (previous) (diff)

comment:7 Changed 2 months ago by claudep

  • Resolution changed from wontfix to fixed
Note: See TracTickets for help on using tickets.
Back to Top