date:20141001

Re: [Django] #23482: SingleObjectMixin.get_object() should allow lookup by BOTH pk and slug

2014-10-01 Thread Django

#23482: SingleObjectMixin.get_object() should allow lookup by BOTH pk and slug
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I will do a final review tomorrow.

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

Re: [Django] #23493: Defining bilateral lookup transformations

2014-10-01 Thread Django

#23493: Defining bilateral lookup transformations
-+-
 Reporter:  tchaumeny|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * type:  Uncategorized => New feature
 * stage:  Accepted => Ready for checkin


Comment:

 Needs a more thorough ORM review, but looking good to me.

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

Re: [Django] #23581: Changing model field choices results in spurious migrations

2014-10-01 Thread Django

#23581: Changing model field choices results in spurious migrations
---+--
 Reporter:  john_scott |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.7
 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
---+--
Description changed by john_scott:

Old description:

> Consider a simple model:
>
> {{{#!python
> from django.db import models
>
> CHOICES = (
> ('1', '1'),
> )
>
> class BasicModel(models.Model):
> choices = models.CharField(choices=CHOICES, max_length=100)
> }}}
>
> If CHOICES is changed e.g. CHOICES += (('2', '2'),), then
> `makemigrations` insists on creating a new migration for this change.
> However, the migration appears to mostly be a no-op. `sqlmigrate` on
> PostgreSQL shows:
> {{{
> BEGIN;
> ALTER TABLE "core_basicmodel" ALTER COLUMN "choices" DROP DEFAULT;
>
> COMMIT;
> }}}
>
> Which is slightly strange since the initial migration never set a
> DEFAULT, so there is nothing to DROP.
>
> I first noticed this working with django-cms (see
> https://github.com/divio/django-cms/issues/3479). In some cases when I
> attempt to make a migration for an unrelated app, `makemigrations` will
> forcefully create a migration for the `cms` app because the
> settings.CMS_TEMPLATES choices have changed. It then makes this
> automatically created migration (which is output in the virtualenv e.g.
> `env/src/django-cms/cms/migrations_django`) a dependency for the
> migration I actually intended to create. There doesn't appear to be a way
> to avoid this. This means I now have a migration I actually need for one
> of my apps that is completely dependent on me creating a migration for a
> third party app, which I don't directly control, resulting in migrations
> that are broken for other developers.
>
> This can also happen when the choices differ in development vs
> deployment, Django will complain:
> {{{
>   Your models have changes that are not yet reflected in a migration, and
> so won't be applied.
>   Run 'manage.py makemigrations' to make new migrations, and then re-run
> 'manage.py migrate' to apply them.
> }}}
> So far this seems to mostly be harmless if slightly confusing/annoying. I
> am not familiar with the migration internals, but since 'choices' isn't
> used (at least not on PostgreSQL) to make any actual alterations to the
> database shouldn't it ignore this attribute?

New description:

 Consider a simple model:

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

 CHOICES = (
 ('1', '1'),
 )

 class BasicModel(models.Model):
 choices = models.CharField(choices=CHOICES, max_length=100)
 }}}

 If CHOICES is changed e.g. CHOICES += (('2', '2'),), then `makemigrations`
 insists on creating a new migration for this change. However, the
 migration appears to mostly be a no-op. `sqlmigrate` on PostgreSQL shows:
 {{{
 BEGIN;
 ALTER TABLE "core_basicmodel" ALTER COLUMN "choices" DROP DEFAULT;

 COMMIT;
 }}}

 Which is slightly strange since the initial migration never set a DEFAULT,
 so there is nothing to DROP.

 I first noticed this working with django-cms (see https://github.com/divio
 /django-cms/issues/3479). In some cases when I attempt to make a migration
 for an unrelated app, `makemigrations` will forcefully create a migration
 for the `cms` app because the settings.CMS_TEMPLATES choices have changed.
 It then makes this automatically created migration (which is output in the
 virtualenv e.g. `env/src/django-cms/cms/migrations_django`) a dependency
 for the migration I actually intended to create. There doesn't appear to
 be a way to avoid this. This means I now have a migration I actually need
 for one of my apps that is completely dependent on me creating a migration
 for a third party app, which I don't directly control, resulting in
 migrations that are broken for other developers.

 This can also happen when the choices differ in development vs deployment,
 Django will complain:
 {{{
   Your models have changes that are not yet reflected in a migration, and
 so won't be applied.
   Run 'manage.py makemigrations' to make new migrations, and then re-run
 'manage.py migrate' to apply them.
 }}}
 I am not familiar with the migration internals, but since 'choices' isn't
 used (at least not on PostgreSQL) to make any actual alterations to the
 database shouldn't it ignore this attribute?

--

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

-- 
You received this message

Re: [Django] #23581: Changing model field choices results in spurious migrations

2014-10-01 Thread Django

#23581: Changing model field choices results in spurious migrations
---+--
 Reporter:  john_scott |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.7
 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 john_scott):

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


Old description:

> Consider a simple model:
>
> {{{#!python
> from django.db import models
>
> CHOICES = (
> ('1', '1'),
> )
>
> class BasicModel(models.Model):
> choices = models.CharField(choices=CHOICES, max_length=100)
> }}}
>
> If CHOICES is changed e.g. CHOICES += (('2', '2'),), then
> `makemigrations` insists on creating a new migration for this change.
> However, the migration appears to mostly be a no-op. `sqlmigrate` on
> PostgreSQL shows:
> {{{
> BEGIN;
> ALTER TABLE "core_basicmodel" ALTER COLUMN "choices" DROP DEFAULT;
>
> COMMIT;
> }}}
>
> Which is slightly strange since the initial migration never set a
> DEFAULT, so there is nothing to DROP.
>
> I first noticed this working with django-cms (see
> https://github.com/divio/django-cms/issues/3479). In some cases when I
> attempt to make a migration for an unrelated app, `makemigrations` will
> forcefully create a migration for the `cms` app because the
> settings.CMS_TEMPLATES choices have changed. It then makes this
> automatically created migration a dependency for the migration I actually
> intended to create. There doesn't appear to be a way to avoid this.
>
> This can also happen when the choices differ in development vs
> deployment, Django will complain:
> {{{
>   Your models have changes that are not yet reflected in a migration, and
> so won't be applied.
>   Run 'manage.py makemigrations' to make new migrations, and then re-run
> 'manage.py migrate' to apply them.
> }}}
> So far this seems to mostly be harmless if slightly confusing/annoying. I
> am not familiar with the migration internals, but since 'choices' isn't
> used (at least not on PostgreSQL) to make any actual alterations to the
> database shouldn't it ignore this attribute?

New description:

 Consider a simple model:

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

 CHOICES = (
 ('1', '1'),
 )

 class BasicModel(models.Model):
 choices = models.CharField(choices=CHOICES, max_length=100)
 }}}

 If CHOICES is changed e.g. CHOICES += (('2', '2'),), then `makemigrations`
 insists on creating a new migration for this change. However, the
 migration appears to mostly be a no-op. `sqlmigrate` on PostgreSQL shows:
 {{{
 BEGIN;
 ALTER TABLE "core_basicmodel" ALTER COLUMN "choices" DROP DEFAULT;

 COMMIT;
 }}}

 Which is slightly strange since the initial migration never set a DEFAULT,
 so there is nothing to DROP.

 I first noticed this working with django-cms (see https://github.com/divio
 /django-cms/issues/3479). In some cases when I attempt to make a migration
 for an unrelated app, `makemigrations` will forcefully create a migration
 for the `cms` app because the settings.CMS_TEMPLATES choices have changed.
 It then makes this automatically created migration (which is output in the
 virtualenv e.g. `env/src/django-cms/cms/migrations_django`) a dependency
 for the migration I actually intended to create. There doesn't appear to
 be a way to avoid this. This means I now have a migration I actually need
 for one of my apps that is completely dependent on me creating a migration
 for a third party app, which I don't directly control, resulting in
 migrations that are broken for other developers.

 This can also happen when the choices differ in development vs deployment,
 Django will complain:
 {{{
   Your models have changes that are not yet reflected in a migration, and
 so won't be applied.
   Run 'manage.py makemigrations' to make new migrations, and then re-run
 'manage.py migrate' to apply them.
 }}}
 So far this seems to mostly be harmless if slightly confusing/annoying. I
 am not familiar with the migration internals, but since 'choices' isn't
 used (at least not on PostgreSQL) to make any actual alterations to the
 database shouldn't it ignore this attribute?

--

--
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

Re: [Django] #23580: forms.fields.NullBooleanField does not honor required=True

2014-10-01 Thread Django

#23580: forms.fields.NullBooleanField does not honor required=True
---+--
 Reporter:  jdufresne  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  master
 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 jdufresne):

 * cc: jon.dufresne@… (added)
 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

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

[Django] #23581: Changing model field choices results in spurious migrations

2014-10-01 Thread Django

#23581: Changing model field choices results in spurious migrations
---+
 Reporter:  john_scott |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Consider a simple model:

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

 CHOICES = (
 ('1', '1'),
 )

 class BasicModel(models.Model):
 choices = models.CharField(choices=CHOICES, max_length=100)
 }}}

 If CHOICES is changed e.g. CHOICES += (('2', '2'),), then `makemigrations`
 insists on creating a new migration for this change. However, the
 migration appears to mostly be a no-op. `sqlmigrate` on PostgreSQL shows:
 {{{
 BEGIN;
 ALTER TABLE "core_basicmodel" ALTER COLUMN "choices" DROP DEFAULT;

 COMMIT;
 }}}

 Which is slightly strange since the initial migration never set a DEFAULT,
 so there is nothing to DROP.

 I first noticed this working with django-cms (see https://github.com/divio
 /django-cms/issues/3479). In some cases when I attempt to make a migration
 for an unrelated app, `makemigrations` will forcefully create a migration
 for the `cms` app because the settings.CMS_TEMPLATES choices have changed.
 It then makes this automatically created migration a dependency for the
 migration I actually intended to create. There doesn't appear to be a way
 to avoid this.

 This can also happen when the choices differ in development vs deployment,
 Django will complain:
 {{{
   Your models have changes that are not yet reflected in a migration, and
 so won't be applied.
   Run 'manage.py makemigrations' to make new migrations, and then re-run
 'manage.py migrate' to apply them.
 }}}
 So far this seems to mostly be harmless if slightly confusing/annoying. I
 am not familiar with the migration internals, but since 'choices' isn't
 used (at least not on PostgreSQL) to make any actual alterations to the
 database shouldn't it ignore this attribute?

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

Re: [Django] #22479: Support byte range requests in django.views.static.serve

2014-10-01 Thread Django

#22479: Support byte range requests in django.views.static.serve
---+
 Reporter:  slurms |Owner:  slurms
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by mdj2):

 What is the preferred way to implement this feature? I went the simplest
 route and hacked on just `django.views.static.serve` whereas slurms
 creates a reusable PartialHttpResponse class. My implementation does not
 support multipart/byteranges requests, but slurms' does. (I don't know of
 any user-agent that makes those kinds of requests though.)

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

[Django] #23580: forms.fields.NullBooleanField does not honor required=True

2014-10-01 Thread Django

#23580: forms.fields.NullBooleanField does not honor required=True
---+
Reporter: jdufresne | Owner: nobody
Type: Uncategorized | Status: new
Component: Forms |Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
I use `forms.fields.NullBooleanField` to allow a user to select Yes, No or
Unknown (Unknown may also mean "no answer"). Sometimes -- depending on the
site configuration -- this field should be required, other times not. In
this case, required means that either Yes or No should be selected. The
field should *not* be left blank (Unknown or "no answer"). Currently, when
`required=True` is set, `forms.fields.NullBooleanField.validate()` does
nothing and will simply validate all values.

I can't use `forms.fields.BooleanField` because when `required=True` is
set Yes *must* be selected for the field to validate.

This topic has come up in the past:

I propose `forms.fields.NullBooleanField` be altered to handle required.
That is change validate to:

{{{
def validate(self, value):
if value is None and self.required:
raise ValidationError(
}}}

I'll happily create a pull request to achieve this. One concern will be
backwards compatibility. But seeing as how `required=True` had no effect
on the field originally, I see no reason anyone would set it and expect
something useful other than what has been suggested above.

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

[django/django] 32c7d3: Fixed #15089 -- Allowed contrib.sites to lookup th...

2014-10-01 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 32c7d3c061b83e9206ef2bf13fbc302a1998f317
  
https://github.com/django/django/commit/32c7d3c061b83e9206ef2bf13fbc302a1998f317
  Author: Tim Graham 
  Date:   2014-10-01 (Wed, 01 Oct 2014)

  Changed paths:
M django/contrib/contenttypes/views.py
M django/contrib/sites/middleware.py
M django/contrib/sites/models.py
M django/contrib/sites/shortcuts.py
M django/contrib/sites/tests.py
M docs/ref/contrib/sites.txt
M docs/releases/1.8.txt

  Log Message:
  ---
  Fixed #15089 -- Allowed contrib.sites to lookup the current site based on 
request.get_host().

Thanks Claude Paroz, Riccardo Magliocchetti, and Damian Moore
for contributions to the patch.


-- 
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/542c62ca770a_501e3fcd53edd2c02231e%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15089: contrib.sites and multitenancy

2014-10-01 Thread Django

#15089: contrib.sites and multitenancy
---+
 Reporter:  legutierr  |Owner:  apollo13
 Type:  New feature|   Status:  closed
Component:  contrib.sites  |  Version:
 Severity:  Normal |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"32c7d3c061b83e9206ef2bf13fbc302a1998f317"]:
 {{{
 #!CommitTicketReference repository=""
 revision="32c7d3c061b83e9206ef2bf13fbc302a1998f317"
 Fixed #15089 -- Allowed contrib.sites to lookup the current site based on
 request.get_host().

 Thanks Claude Paroz, Riccardo Magliocchetti, and Damian Moore
 for contributions to the patch.
 }}}

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

Re: [Django] #14286: Support for BigAutoField

2014-10-01 Thread Django

#14286: Support for BigAutoField
-+-
 Reporter:  hongrich |Owner:  mmcnickle
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by timgraham):

 I don't see any progress. It would be included in Django 1.8 at the
 earliest. You can read about our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions support versions policy].

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

[Django] #23579: Default Geometry representation from WKT to EWKT

2014-10-01 Thread Django

#23579: Default Geometry representation from WKT to EWKT
---+
Reporter: claudep | Owner: nobody
Type: New feature | Status: new
Component: GIS |Version: master
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|
---+
Currently, the default `__str__` representation of a `GEOSGeometry` object
is its WKT representation (e.g. `"POINT (1 2)"`).
I'd like to suggest moving to the EWKT representation which includes the
SRID information (e.g. `"SRID=4326;POINT (1 2)"`).
For me, coordinates without SRID is like an encoded string without knowing
its encoding, or a datetime object without the timezone.

The change is trivial. There is a small backwards compatibility issue,
essentially for people testing the output of `str(geom)`, and it also
means that the SRID will also appear in `loaddata` output, which is
welcome in my opinion.

Comments welcome.

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

Re: [Django] #22800: FormWizards leak data into other forms.

2014-10-01 Thread Django

* cc: mail@… (added)

Comment:

Is there really a change to Django necessary? Daniel could just override
get_prefix in his view and return a prefix based on his event ID. I just
thought about how I'd design an API to provide an "instance specific key",
als you put it, and what I came up with was exactly what get_prefix
already is.

If you think there should be another way to do this, I'd like to work on
this as my first contribution to Django itself, as I will have the same
use case in one of my current projects.

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

[django/django] 333960: Added a dumpdata/loaddata test for geographic cont...

2014-10-01 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 333960582170457473aafe24dbcb8502af7d8ffc
  
https://github.com/django/django/commit/333960582170457473aafe24dbcb8502af7d8ffc
  Author: Claude Paroz 
  Date:   2014-10-01 (Wed, 01 Oct 2014)

  Changed paths:
M django/contrib/gis/geos/geometry.py
M django/contrib/gis/tests/geoapp/tests.py

  Log Message:
  ---
  Added a dumpdata/loaddata test for geographic content


-- 
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/542c56ec5dbf4_7ba83ff2fbfad2b863849%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14286: Support for BigAutoField

2014-10-01 Thread Django

#14286: Support for BigAutoField
-+-
 Reporter:  hongrich |Owner:  mmcnickle
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by stodge):

 * cc: stodge@… (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/066.4f2fcf74d780e387d5e80979ceee2d0f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14286: Support for BigAutoField

2014-10-01 Thread Django

#14286: Support for BigAutoField
-+-
 Reporter:  hongrich |Owner:  mmcnickle
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by stodge):

 Has there been any progress on this ticket? Is there a chance it will be
 included (and back-ported to 1.6)?

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

Re: [Django] #23335: Related fields pointing to custom fields that store different values in the database than the python representation do not remember selections

2014-10-01 Thread Django

#23335: Related fields pointing to custom fields that store different values in 
the
database than the python representation do not remember selections
---+--
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.7-rc-2
 Severity:  Normal |   Resolution:  needsinfo
 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 timgraham):

 Yes, please reopen when you provide more details showing what the bug is
 then I'll be happy to take another look.

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

Re: [Django] #23335: Related fields pointing to custom fields that store different values in the database than the python representation do not remember selections

2014-10-01 Thread Django

#23335: Related fields pointing to custom fields that store different values in 
the
database than the python representation do not remember selections
---+--
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.7-rc-2
 Severity:  Normal |   Resolution:  needsinfo
 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 thenewguy):

 Hello Tim.  I am happy to spend more time on this.  I am covered up for a
 few weeks with deadlines.  Can we reopen this issue?

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

[django/django] b21ec1: [1.7.x] Added flat=False to signature of QuerySet....

2014-10-01 Thread GitHub

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: b21ec1ab6e92c1d35edca4a71e01f928ef0e1656
  
https://github.com/django/django/commit/b21ec1ab6e92c1d35edca4a71e01f928ef0e1656
  Author: jnothman 
  Date:   2014-10-01 (Wed, 01 Oct 2014)

  Changed paths:
M docs/ref/models/querysets.txt

  Log Message:
  ---
  [1.7.x] Added flat=False to signature of QuerySet.values_list()

Backport of 20f868bc5a from master


-- 
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/542c357ea31e4_78d13fce5305529c2446c%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] 000415: [1.6.x] Added flat=False to signature of QuerySet....

2014-10-01 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 000415687323a7a7342eb2ec7e1bb1801613a652
  
https://github.com/django/django/commit/000415687323a7a7342eb2ec7e1bb1801613a652
  Author: jnothman 
  Date:   2014-10-01 (Wed, 01 Oct 2014)

  Changed paths:
M docs/ref/models/querysets.txt

  Log Message:
  ---
  [1.6.x] Added flat=False to signature of QuerySet.values_list()

Backport of 20f868bc5a from master


-- 
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/542c3580bd43f_72913fbb07b672c0131db%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] 20f868: Added flat=False to signature of QuerySet.values_l...

2014-10-01 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 20f868bc5a7178849db9c671e684825ce2cf6107
  
https://github.com/django/django/commit/20f868bc5a7178849db9c671e684825ce2cf6107
  Author: jnothman 
  Date:   2014-10-01 (Wed, 01 Oct 2014)

  Changed paths:
M docs/ref/models/querysets.txt

  Log Message:
  ---
  Added flat=False to signature of QuerySet.values_list()


-- 
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/542c3567b0147_501e3fcd53edd2c0153d0%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23299: Add some interoperability to _() function calls parsing in templatize function.

2014-10-01 Thread Django

#23299: Add some interoperability to _() function calls parsing in templatize
function.
--+
 Reporter:  niwibe|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  template-refactor | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * cc: template-refactor (removed)
 * keywords:   => template-refactor


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

Re: [Django] #23299: Add some interoperability to _() function calls parsing in templatize function.

2014-10-01 Thread Django

#23299: Add some interoperability to _() function calls parsing in templatize
function.
--+
 Reporter:  niwibe|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * cc: template-refactor (added)
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


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

Re: [Django] #23566: Incorrect timezone handling in feed community blog post aggregator?

2014-10-01 Thread Django

#23566: Incorrect timezone handling in feed community blog post aggregator?
-+
 Reporter:  foxmask  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  *.djangoproject.com  |  Version:
 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
-+

Comment (by timgraham):

 Care to submit a pull request?

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

Re: [Django] #23566: Incorrect timezone handling in feed community blog post aggregator?

2014-10-01 Thread Django

#23566: Incorrect timezone handling in feed community blog post aggregator?
-+
 Reporter:  foxmask  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  *.djangoproject.com  |  Version:
 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
-+

Comment (by foxmask):

 from the models.py I see here
 
https://github.com/django/djangoproject.com/blob/master/aggregator/models.py#L159-164,
 on my side, I had to do this to handle the same behavior
 https://github.com/foxmask/django-
 th/blob/master/django_th/management/commands/fire_th.py#L36-43 but without
 dropping the end of the date (by using [:6] if 'im not wrong) makes more
 problem than it solves them.

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

Re: [Django] #22377: SQL Logging throws an exception when fields have utf-8 characters

2014-10-01 Thread Django

#22377: SQL Logging throws an exception when fields have utf-8 characters
-+-
 Reporter:  rolanvc@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  sql logging for  |  Unreviewed
  utf-8  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

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


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

Re: [Django] #23566: Incorrect timezone handling in feed community blog post aggregator? (was: On "Community blog posts" Feeds RSS updated for nothing)

2014-10-01 Thread Django

#23566: Incorrect timezone handling in feed community blog post aggregator?
-+
 Reporter:  foxmask  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  *.djangoproject.com  |  Version:
 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 timgraham):

 * version:  1.7 =>
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 I guess we have timezone issues in the `feed_updated()` function of the
 models.py file here:
 https://github.com/django/djangoproject.com/tree/master/aggregator.

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

Re: [Django] #23566: On "Community blog posts" Feeds RSS updated for nothing

2014-10-01 Thread Django

#23566: On "Community blog posts"  Feeds RSS updated for nothing
-+-
 Reporter:  foxmask  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  *.djangoproject.com  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by foxmask):

 Hi,

 the two date are different as one of them use a TIMEZONE (-0500) and not
 the second one. I'm not a datetime expert but may be this should be handle
 in the piece of code you linked above ?

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

Re: [Django] #23518: Subquery does not respect explicit __exact

2014-10-01 Thread Django

#23518: Subquery does not respect explicit __exact
-+-
 Reporter:  john-parton  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  subquery subselect   |  Unreviewed
  exact  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

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


Comment:

 If you expect the query to return one result, why not use `.get()` instead
 of `.filter()`. Also couldn't you restructure your example more simply as
 `Parent.objects.filter(parent__slug='test')`. I guess some documentation
 could at least be updated.

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

Re: [Django] #23549: Model form's model_to_dict using value_from_object instead of to_python

2014-10-01 Thread Django

#23549: Model form's model_to_dict using value_from_object instead of to_python
-+-
 Reporter:  mwaterfall   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.7
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  form, modelform, | Triage Stage:
  field  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 In the case of `ModelChoiceField`, `to_python()` might return a model
 class while `value_from_object()` returns the value's pk such as an
 integer or string. To learn more, make the change you suggest and run
 Django's test suite and see what fails.

 As it isn't evident there is a bug in Django, please see
 TicketClosingReasons/UseSupportChannels for ways to get help. Please
 reopen if you can provide more details that suggests this is indeed a bug
 in Django and not in the custom field. Thanks.

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

Re: [Django] #23270: select_related on fields pointing to subclasses does not work when using defer

2014-10-01 Thread Django

#23270: select_related on fields pointing to subclasses does not work when using
defer
-+-
 Reporter:  islavov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7-rc-2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  select_related   |  Needs documentation:  0
  defer  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


Comment:

 Patch received another update.

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

Re: [Django] #23563: Make `staticfiles_storage` a public API

2014-10-01 Thread Django

#23563: Make `staticfiles_storage` a public API
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 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 timgraham):

 * needs_docs:  1 => 0
 * component:  contrib.staticfiles => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 For this it would be helpful to point to `docs/howto/custom-file-
 storage.txt` which lists the usual methods for storage classes. For
 example, `staticfiles_storage.url('foo.js')` works to get URL.

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

Re: [Django] #23566: On "Community blog posts" Feeds RSS updated for nothing

2014-10-01 Thread Django

#23566: On "Community blog posts"  Feeds RSS updated for nothing
-+-
 Reporter:  foxmask  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  *.djangoproject.com  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Here is the logic for how the feed's `lastBuildDate` is generated:
 
https://github.com/django/django/blob/fe2afcd318493c933ab1191a5a64271869a1227f/django/utils/feedgenerator.py#L194-L209

 I don't understand the issue. It looks like the two dates in your example
 above are the same?

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

Re: [Django] #23571: Empty order_by() doesn't work with slice

2014-10-01 Thread Django

#23571: Empty order_by() doesn't work with slice
-+-
 Reporter:  liminspace   |Owner:
 Type:  Bug  |  liminspace
Component:  Database layer   |   Status:  closed
  (models, ORM)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  order_by, slice  |  worksforme
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I also cannot reproduce the reported issue:

 I added:
 {{{
 class Meta:
 ordering = ('id',)
 }}}
 to the Poll class in the tutorial.

 {{{
 >>> str(Poll.objects.all().query)
 'SELECT "polls_poll"."id", "polls_poll"."question",
 "polls_poll"."pub_date" FROM "polls_poll" ORDER BY "polls_poll"."id" ASC'
 >>> str(Poll.objects.order_by().query)
 'SELECT "polls_poll"."id", "polls_poll"."question",
 "polls_poll"."pub_date" FROM "polls_poll"'
 >>> str(Poll.objects.order_by()[:10].query)
 'SELECT "polls_poll"."id", "polls_poll"."question",
 "polls_poll"."pub_date" FROM "polls_poll" LIMIT 10'
 }}}

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

Re: [Django] #23335: Related fields pointing to custom fields that store different values in the database than the python representation do not remember selections

2014-10-01 Thread Django

#23335: Related fields pointing to custom fields that store different values in 
the
database than the python representation do not remember selections
---+--
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.7-rc-2
 Severity:  Normal |   Resolution:  needsinfo
 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 timgraham):

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


Comment:

 I think we really need more effort on your part in suggesting a solution
 since the example is quite complex and very specialized. Once again, I
 spent over an hour looking at this and couldn't figure out the exact
 issue.

 Something suspicious that seems related to the problem:
 {{{
 >>> a = BarInt.objects.get()
 >>> a.pk
 -15
 >>> # a.pk is a shortcut for a.id_id
 >>> a.id_id
 -15
 >>> a.id
 

 >>> # how form data is generated
 >>> model_to_dict(a)
 {'id': -15}

 >>> # how form choices are generated
 >>> [str(a) for a in FooInt.objects.all()]
 ['185']
 }}}

 I could make the Id and Fk widgets work by adding this method to the
 model:
 {{{
 def serializable_value(self, field_name):
 val = super(FooInt, self).serializable_value(field_name)
 if field_name == 'id':
 return val.db_value
 return val
 }}}
 but this may not be a good solution and I'm not sure if this will cause
 other problems (also m2m didn't work).

 Also it would be helpful to modify your project so that it doesn't use
 `SubFieldBase` to verify the issue still exists without that (I suspect it
 does).

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

Re: [Django] #23549: Model form's model_to_dict using value_from_object instead of to_python

2014-10-01 Thread Django

#23549: Model form's model_to_dict using value_from_object instead of to_python
-+-
 Reporter:  mwaterfall   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  form, modelform, | Triage Stage:
  field  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mshafiq9):

 * cc: mshafiq9 (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 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/068.ce41e34ebf0fd5decfe83ffad111534f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23568: timesince / timeuntil is not localized

2014-10-01 Thread Django

#23568: timesince / timeuntil is not localized
-+-
 Reporter:  lerela   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.7
  Internationalization   |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  l10n, i18n   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by lerela):

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


Comment:

 Turned out I did not realize I was still using RC2. 1.7 does not have this
 bug, even though I don't know when/where it has been solved. Sorry.

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

Re: [Django] #23568: timesince / timeuntil is not localized

2014-10-01 Thread Django

#23568: timesince / timeuntil is not localized
-+-
 Reporter:  lerela   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.7
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  l10n, i18n   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by lerela):

 Same thing. The point of my example is that "regular" strings do get
 translated (I don't have any project-specific locale file to translate
 "password", this is Django's translation), so it is able to find the
 locale files.

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

Re: [Django] #23568: timesince / timeuntil is not localized

2014-10-01 Thread Django

#23568: timesince / timeuntil is not localized
-+-
 Reporter:  lerela   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.7
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  l10n, i18n   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mpessas):

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


Comment:

 Can you try using the "es" as language code in your settings instead of
 es_ES? This is what django uses [1].

 IIRC, gettext will fallback to English, if it cannot find the files that
 correspond to the correct locale, which could explain the weird behavior
 here.

 The code looks correct to me with a quick look.

 [1]: https://github.com/django/django/tree/master/django/conf/locale/es

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

39 matches

Mail list logo