Re: [Django] #26424: Allow URLValidator to skip schemes validation

[Django]

#26424: Allow URLValidator to skip schemes validation
--+
 Reporter:  timgraham |Owner:  burhan
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  1 => 0


--
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/067.1efd58086e97cf4499a767fe44553f7d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26643: AlterModelManagers migration is generated for all Models with custom Managers pointing to the default Django Manager

[Django]

#26643: AlterModelManagers migration is generated for all Models with custom
Managers pointing to the default Django Manager
-+-
 Reporter:  cybojenix|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.10 | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by loic):

 Hi cybojenix, could you still provide code examples? I'd like to ensure
 it's the ideal behavior.

--
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/067.19523b2f6ebd3516af3854672451919f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26623: Customizing environment variable for RemoteUserMiddleware requires subclass

[Django]

#26623: Customizing environment variable for RemoteUserMiddleware requires 
subclass
--+--
 Reporter:  adelton   |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by carljm):

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


Comment:

 I fully agree with Aymeric, but I'll go one step further and close the
 ticket: I just don't think this use case is common enough to deserve its
 own built-in setting. If you need it, it's easy enough to add the class to
 your project once, and then never have to think about it again.

--
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.70e63d178e27181515e6c2f15820f566%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26618: Improve error message when AppConfig.name is invalid

[Django]

#26618: Improve error message when AppConfig.name is invalid
-+--
 Reporter:  alasdairnicol|Owner:
 Type:  Uncategorized|   Status:  new
Component:  Error reporting  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+--
Changes (by inondle):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * needs_tests:  0 => 1
 * needs_docs:  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/071.567ae1fdff7e7d71c7485dc0725fe6ac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26618: Improve error message when AppConfig.name is invalid

[Django]

#26618: Improve error message when AppConfig.name is invalid
-+--
 Reporter:  alasdairnicol|Owner:
 Type:  Uncategorized|   Status:  new
Component:  Error reporting  |  Version:  master
 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 inondle):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 This seems like a good idea to me, I made a preliminary pull request here
 for it: https://github.com/django/django/pull/6632

 I'm still not sure where to put tests for it or where to edit the docs but
 I'll look around.

--
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/071.0a82b50b6f88d4613f48f1a84439fd9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26643: AlterModelManagers migration is generated for all Models with custom Managers pointing to the default Django Manager

[Django]

#26643: AlterModelManagers migration is generated for all Models with custom
Managers pointing to the default Django Manager
-+-
 Reporter:  cybojenix|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.10 | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * cc: loic (added)
 * keywords:   => 1.10
 * component:  Migrations => Documentation
 * type:  Uncategorized => Cleanup/optimization


--
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/067.da70f3dad65ee4b9c0ad41f451facfa2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26643: AlterModelManagers migration is generated for all Models with custom Managers pointing to the default Django Manager

[Django]

#26643: AlterModelManagers migration is generated for all Models with custom
Managers pointing to the default Django Manager
---+--
 Reporter:  cybojenix  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  master
 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 cybojenix):

 * type:  Bug => Uncategorized


--
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/067.6a9752b8a6a544cca0b000c0cdd83e93%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26643: AlterModelManagers migration is generated for all Models with custom Managers pointing to the default Django Manager

[Django]

#26643: AlterModelManagers migration is generated for all Models with custom
Managers pointing to the default Django Manager
+--
 Reporter:  cybojenix   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 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 cybojenix):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Further investigation shows that if you have a manager without
 `use_in_migrations` set, it will explicitly set the default manager in
 `AlterModelManagers` instead of the previous behaviour of not creating a
 migration at all (ie, the migration treats the model as if no manager has
 been set at all).

 As such, I'm going to remove the bug label, however it would be good to
 mention this in the release notes to avoid questions down the road.

--
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/067.78893258f2ad116ff3599fc857201a10%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26643: AlterModelManagers migration is generated for all Models with custom Managers pointing to the default Django Manager

[Django]

#26643: AlterModelManagers migration is generated for all Models with custom
Managers pointing to the default Django Manager
+
 Reporter:  cybojenix   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Working on a project with Models written with migrations generated by
 Django 1.8 (upgraded to 1.9), when running `makemigrations`, some
 unexpected migrations were generated.

 {{{#!python
 ...
 migrations.AlterModelManagers(
 name='some_model',
 managers=[
 ('objects', django.db.models.manager.Manager()),
 ],
 ),
 }}}

 We've never run `AlterModelManagers` in the past. Instead of the Manager
 we define being added, the default Manager is being set.

 I can add code examples + instructions later

--
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/052.ad15ab5d1c17043f870aa8a547615405%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26641: Unable to concatenate 2 fields when filtering

[Django]

#26641: Unable to concatenate 2 fields when filtering
-+-
 Reporter:  FoxPotato|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 You should be able to use the
 [https://docs.djangoproject.com/en/1.9/ref/models/database-
 functions/#concat Concat] functions for this purpose:

 {{{
 from django.db.models import Value
 from django.db.models.functions import Concat

 User.objects.annotate(
 name=Concat('first_name', Value(' '), 'last_name'),
 ).filter(name__icontains=value)
 }}}

 Or simply using `Q` objects:

 {{{#!python
 from django.db.models import Q

 User.objects.annotate.filter(
 Q(first_name__icontains=value) | Q(last_name__icontains=value),
 )
 }}}

--
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/067.205771f882a31525b739b78beffe0369%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #10919: Add an option to disable display of related items on admin's delete confirmation page (to prevent large memory usage on complex objects)

[Django]

#10919: Add an option to disable display of related items on admin's delete
confirmation page (to prevent large memory usage on complex objects)
+
 Reporter:  tobias  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  admin memory limit  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by nijel):

 * cc: michal@… (added)


--
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.dc08d37f4d65ad770fed69ae25453163%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #10919: Add an option to disable display of related items on admin's delete confirmation page (to prevent large memory usage on complex objects)

[Django]

#10919: Add an option to disable display of related items on admin's delete
confirmation page (to prevent large memory usage on complex objects)
+
 Reporter:  tobias  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  admin memory limit  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by nijel):

 Adding such property to ModelAdmin sounds like a good idea.

 I've workarounded it myself by removing deleted_objects before rendering
 the template:

 {{{
 def render_delete_form(self, request, context):
 context['deleted_objects'] = [_('Object listing disabled')]
 return super(ProjectAdmin, self).render_delete_form(request,
 context)
 }}}

 This way I will get the summary (so that user has idea what he is
 deleting), but not object list as it is too long to get displayed.

--
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.205c8a6e6696a75e6e46f15fd89a329e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26623: Customizing environment variable for RemoteUserMiddleware requires subclass

[Django]

#26623: Customizing environment variable for RemoteUserMiddleware requires 
subclass
--+--
 Reporter:  adelton   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by aaugustin):

 I'm not sure what's wrong with:

 {{{
 class CustomRemoteUserMiddleware(RemoteUserMiddleware):
 header = os.environ['DJANGO_REMOTE_USER_VAR']
 }}}

 Features are usually configured with settings in Django. In "devops
 environments" these settings are initialized from environment variables.

 I'm -0 on adding a setting to tackle this specific use case and -1 on
 using a environment variable that won't be visible e.g. in `diffsettings`.

--
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.f41a8c8a19fa1049271e3457d27b7eba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25677: compilemessages throws an exception and does not report msgformat errors correctly

[Django]

#25677: compilemessages throws an exception and does not report msgformat errors
correctly
--+
 Reporter:  gavinwahl |Owner:  ramiro
 Type:  Bug   |   Status:  assigned
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  1.10 windows  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by ramiro):

 * owner:   => ramiro
 * status:  new => assigned


--
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/067.818c169d5848a49c2ebda40f6e57ef34%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26640: class_prepared is not a ModelSignal and differs from documentation

[Django]

#26640: class_prepared is not a ModelSignal and differs from documentation
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 #24313 suggests to deprecated the `class_prepared` signal. Do you see a
 reason not to move forward with that instead?

--
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.c3eb1677a364d327d7e7f132f5616032%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26642: ModelSignal.disconnect() does not work with lazy references

[Django]

#26642: ModelSignal.disconnect() does not work with lazy references
--+
 Reporter:  AlexHill  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 `ModelSignal.connect()` lets you pass a string model reference as a
 sender, and will connect the signal as soon as the model is available.

 For consistency, `ModelSignal.disconnect()` should work in the same way.
 Currently, if you call `connect()` followed by `disconnect()` before the
 model is available, the signal will remain connected:

 {{{#!python

 >>> def receiver(sender, **kwargs):
 ... print("post_init sent by %r" % sender)
 ...
 >>> post_init.connect(receiver, sender='some_app.SomeModel')
 >>> post_init.disconnect(receiver, sender='some_app.SomeModel')
 False
 >>>
 >>> class SomeModel(models.Model):
 ... class Meta:
 ... app_label = 'some_app'
 ...
 >>> s = SomeModel()
 post_init sent by 
 >>>
 }}}

 There's a patch with the necessary changes in PR 6629.

--
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.72eafa552df7da4b434044b06a315cb2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26641: Unable to concatenate 2 fields when filtering

[Django]

#26641: Unable to concatenate 2 fields when filtering
--+
 Reporter:  FoxPotato |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:  QuerySet.extra
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The docs said I should file a ticket when using the extra API.

 I just need a way to use the icontains field lookup on 2 fields at once,
 for example the full name (first_name + last_name) of a user.

 I managed it using the extra API like this:
 {{{
 User.objects.extra(where=['upper(concat(first_name, " ", last_name)) LIKE
 upper(%s)'], params=[query])
 }}}

--
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/052.b2d204eafd8cded561515996b274a367%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #4136: CharField(null=True, blank=True, unique=True)

[Django]

#4136: CharField(null=True, blank=True, unique=True)
-+-
 Reporter:  David Cramer |Owner:
  |
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3-rc
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * owner:  aashu_dwivedi =>
 * status:  assigned => new
 * needs_docs:  1 => 0
 * needs_tests:  1 => 0
 * needs_better_patch:  1 => 0


--
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/090.d0611e0010bd592d4d00a09ce6b7da9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.