Re: [Django] #27629: Inconsistent check of allow_relation in ForwardManyToOneDescriptor.__set__

2018-05-10 Thread Django 
#27629: Inconsistent check of allow_relation in 
ForwardManyToOneDescriptor.__set__
-+-
 Reporter:  Sven Coenye  |Owner:  Stefan R.
 |  Filipek
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  allow_relation   | Triage Stage:  Accepted
  ForwardManyToOneDescriptor |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"a5a2ceeb453b86caaf01687342984f372428beb8" a5a2cee]:
 {{{
 #!CommitTicketReference repository=""
 revision="a5a2ceeb453b86caaf01687342984f372428beb8"
 Fixed #27629 -- Added router.allow_relation() calls for assignments
 between unsaved model instances.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.3e8a250f1f024f091637949ede9da276%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29396: Using date__year comparisons together with OuterRef causes an IndexError

2018-05-10 Thread Django 
#29396: Using date__year comparisons together with OuterRef causes an IndexError
-+-
 Reporter:  Dmitry Shachnev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * version:   => master
 * stage:  Unreviewed => Accepted


Comment:

 Reproduced on master at 9c4ea63e878c053600c284e32d5f32d27a59b63a.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.9336b5e016fc8601adbdaf3100f535df%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29397: Username validation should be handled at the model level on object creation.

2018-05-10 Thread Django 
#29397: Username validation should be handled at the model level on object
creation.
---+--
 Reporter:  Andrew Carl|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 It's not clear to me where the problem is and why Django is at fault. Can
 you investigate a bit further or explain what change is required?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.42d995d91870455639463075c01ceaa9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29397: Username validation should be handled at the model level on object creation.

2018-05-10 Thread Django 
#29397: Username validation should be handled at the model level on object
creation.
-+
   Reporter:  Andrew Carl|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I have a rather large django system that conglomerates users from a bunch
 of systems into a single platform. In order to prevent duplicate
 usernames, I am constructing usernames like:
 |. I am able to successfully create and
 modify the user object with direct calls to the database. However,
 attempting to modify another username field in the admin site returns a
 validation error. I have attempted to overwrite this form-level validation
 like so:
 {{{
 admin.site.unregister(User)
 username_field = forms.RegexField(label="Username", max_length=150,
 regex=r'^.+$',
 help_text = "Required. 30 characters or fewer. Letters, digits and "
   "@/./+/-/_/| only.",
 error_messages = {
 'invalid': "This value may contain only letters, numbers and "
  "@/./+/-/_/| characters."})

 class MyUserCreationForm(UserCreationForm):
 username = username_field

 class MyUserChangeForm(UserChangeForm):
 username = username_field

 @admin.register(User)
 class MyUserAdmin(UserAdmin):
 add_form = MyUserCreationForm
 form = MyUserChangeForm
 }}}

 This, however will return the error:
  This value may contain only letters, numbers and @/./+/-/_/| characters.

 This leads me to believe that my user admin form is correctly being
 overridden, as my custom error message is displayed. I am currently able
 to modify and save my user model by setting the 'username' field to be
 read only.

 The fact that I am able to save on the out of the box user model with an
 "invalid" character, but then have the stock admin site break I would
 consider unexpected behavior. This would be acceptable if the form
 validator was able to be overridden or if I was thrown an exception on
 object creation.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.db964d204aa789175ddd2399b0151512%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21408: Fallback to timesince produces erroneous translations in naturaltime

2018-05-10 Thread Django 
#21408: Fallback to timesince produces erroneous translations in naturaltime
-+-
 Reporter:  676c7473@…   |Owner:
 |  Maximilian Merz
 Type:  Bug  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  i18n l10n| Triage Stage:  Ready for
  translation|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"78912ccd0e1fcdfe98ca85081c9eb8acb7aa1f6d" 78912ccd]:
 {{{
 #!CommitTicketReference repository=""
 revision="78912ccd0e1fcdfe98ca85081c9eb8acb7aa1f6d"
 Fixed #21408 — German Translation for “3 days ago”

 The problem:
 “3 days ago” should translate to “vor 3 Tagen” in German, while “3 days”
 translates to “3 Tage”. #21408 describes that django always translated to
 “Tage”, even when the dative “Tagen” was correct. The same applies to
 months (“Monate”/“Monaten”) and years (“Jahre”/“Jahren”).

 The solution:
 Let `timesince` caller provide the string dict to use for the time-related
 strings.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.145fa0509e856c8157df623f49b2bfa4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29396: Using date__year comparisons together with OuterRef causes an IndexError

2018-05-10 Thread Django 
#29396: Using date__year comparisons together with OuterRef causes an IndexError
-+-
 Reporter:  Dmitry Shachnev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Dmitry Shachnev):

 I should add that it happens only with `gte`/`lte` comparisons. If I
 replace `date__year__gte` with `date__year__exact`, then the code works as
 expected.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.52a64af298244cbbd47ad8a8b1260f31%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29396: Using date__year comparisons together with OuterRef causes an IndexError

2018-05-10 Thread Django 
#29396: Using date__year comparisons together with OuterRef causes an IndexError
-+-
 Reporter:  Dmitry Shachnev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Dmitry Shachnev):

 * Attachment "test-project.tar.gz" added.

 Test project to reproduce the bug

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.1f9bb4be86a058f921c068c2094c7de1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29396: Using date__year comparisons together with OuterRef causes an IndexError

2018-05-10 Thread Django 
#29396: Using date__year comparisons together with OuterRef causes an IndexError
-+-
   Reporter:  Dmitry |  Owner:  nobody
  Shachnev   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 With the following models:
 {{{
 #!python
 class ModelWithDate(models.Model):
 id = models.AutoField(primary_key=True)
 date = models.DateField()

 class ModelWithYear(models.Model):
 id = models.AutoField(primary_key=True)
 year = models.IntegerField()
 date_ref = models.ForeignKey(to=ModelWithDate,
 on_delete=models.CASCADE)
 }}}

 the following code:
 {{{
 #!python
 >>> dates = ModelWithDate.objects.filter(date__year__gte=OuterRef("year"))
 >>> dates_subq = Subquery(dates.values("id"))
 >>> ModelWithYear.objects.filter(date_ref__in=dates_subq)
 }}}

 causes an exception:
 {{{
 #!pytb
 Traceback (most recent call last):
   ...
   File "/usr/lib/python3/dist-packages/django/db/models/lookups.py", line
 90, in process_rhs
 sql, params = compiler.compile(value)
   File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py",
 line 391, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/usr/lib/python3/dist-packages/django/db/models/expressions.py",
 line 1041, in as_sql
 template_params['subquery'], sql_params =
 self.queryset.query.get_compiler(connection=connection).as_sql()
   File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py",
 line 459, in as_sql
 where, w_params = self.compile(self.where) if self.where is not None
 else ("", [])
   File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py",
 line 391, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/usr/lib/python3/dist-packages/django/db/models/sql/where.py",
 line 80, in as_sql
 sql, params = compiler.compile(child)
   File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py",
 line 391, in compile
 sql, params = node.as_sql(self, self.connection)
   File "/usr/lib/python3/dist-packages/django/db/models/lookups.py", line
 523, in as_sql
 start, finish = self.year_lookup_bounds(connection, rhs_params[0])
 IndexError: list index out of range
 }}}

 The same happens if I create an annotation using ExtractYear and use it
 directly.

 A small test project is attached. The bug can be reproduced with
 “DJANGO_SETTINGS_MODULE=settings python3 ./test.py”. Tested with Django
 2.0.5 and 1.11.13.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.b20dd41ded6a9d324a8e6075ee510759%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29395: Assigning correctly formatted time string to TimeField field works, but leaves the field value a string (and not datetime.time as when retrieved)

2018-05-10 Thread Django 
#29395: Assigning correctly formatted time string to TimeField field works, but
leaves the field value a string (and not datetime.time as when retrieved)
-+-
 Reporter:  Tomer Zekharya   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Duplicate of #27825 (the consensus is to document the limitation).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ff031ee29ec29147ab38ff6170501a25%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21408: Fallback to timesince produces erroneous translations in naturaltime

2018-05-10 Thread Django 
#21408: Fallback to timesince produces erroneous translations in naturaltime
-+-
 Reporter:  676c7473@…   |Owner:
 |  Maximilian Merz
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n l10n| Triage Stage:  Ready for
  translation|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.b9bffbef044eefb8a78201c4ffa2a3a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29394: Broken urls.py instructions in tutorial 1

2018-05-10 Thread Django 
#29394: Broken urls.py instructions in tutorial 1
---+--
 Reporter:  Jln Wntr   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  2.0
 Severity:  Normal |   Resolution:  invalid
 Keywords:  tutorial   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 So this is in the [https://docs.djangoproject.com/en/2.0/intro/tutorial01
 /#write-your-first-view Write your first view] section, in the
 `mysite/urls.py` snippet.

 The full snippet reads:


 {{{
 from django.contrib import admin
 from django.urls import include, path

 urlpatterns = [
 path('polls/', include('polls.urls')),
 path('admin/', admin.site.urls),
 ]
 }}}

 The part you're missing there is:

 {{{
 from django.urls import include, path
 }}}

 Note that it imports `include`, which is exactly the solution from the
 StackOverflow thread.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6a65bf37d1199f8c078a46d50ad6e730%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29395: Assigning correctly formatted time string to TimeField field works, but leaves the field value a string (and not datetime.time as when retrieved)

2018-05-10 Thread Django 
#29395: Assigning correctly formatted time string to TimeField field works, but
leaves the field value a string (and not datetime.time as when retrieved)
-+-
   Reporter:  Tomer  |  Owner:  nobody
  Zekharya   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When initializing a TimeField field with a well formatted time string (i.e
 '12:00:00') and saving the object, it works fine, but leaves the field as
 'str' type and does not convert it to a datetime.time object. This creates
 an inconsistency, where newly saved objects may have 'str' values for
 TimeField fields, while retrieved objects have datetime.time values. The
 docs clearly state that TimeField field in Django is represented as
 datetime.time object in python.

 For example:

 models.py
 {{{
 from django.db import models

 class A(models.Model):
 time = models.TimeField()
 }}}

 And when using this model as described above:

 {{{

 >>> t = A(time='12:10:00')
 >>> t.save()
 >>> type(t.time)
 

 >>> t2 = A.objects.get(id=t.id)
 >>> type(t2.time)
 

 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.0e8af8cd88989ae9eeaf1381f1323f06%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29394: Broken urls.py instructions in tutorial 1

2018-05-10 Thread Django 
#29394: Broken urls.py instructions in tutorial 1
---+--
 Reporter:  Jln Wntr   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  2.0
 Severity:  Normal |   Resolution:
 Keywords:  tutorial   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Jln Wntr):

 * Attachment "dump.txt" added.

 console dump

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f9e8b8542da75ef5542b9e5706b47866%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29394: Broken urls.py instructions in tutorial 1

2018-05-10 Thread Django 
#29394: Broken urls.py instructions in tutorial 1
-+--
   Reporter:  Jln Wntr   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  2.0
   Severity:  Normal |   Keywords:  tutorial
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--
 When adding this to mysite/urls.py

 {{{
 path('polls/', include('polls.urls')),
 }}}

 like described here:
 [https://docs.djangoproject.com/en/2.0/intro/tutorial01/]

 My console dumps this errors: (see attachment)

 NameError: name 'include' is not defined


 This helps: https://stackoverflow.com/questions/34471102/python-nameerror-
 name-include-is-not-defined/34471121#34471121


 Python-version: 3.5.2
 django-version: 2.0.5
 OS: Ubuntu 16.03

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.4c09ba387dd0a6cf0d787073ae88d3f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28687: Add a 'Not Empty' option to admin's related filter

2018-05-10 Thread Django 
#28687: Add a 'Not Empty' option to admin's related filter
-+-
 Reporter:  Brillgen Developers  |Owner:  Jake
 Type:   |  Barber
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.e1a7a8f55e433ec6ddaa5b0c8a714a7e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.