date:20140129

[Django] #21908: Misleading documentation in ModelAdmin.get_inline_instances

2014-01-29 Thread Django

#21908: Misleading documentation in ModelAdmin.get_inline_instances
---+
 Reporter:  matt@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.admin  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The documentation for this method seems a little sparse:

 
https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_inline_instances

 It's not actually clear that you need to instantiate the inline classes in
 this manner:

 return [inline(self.model, self.admin_site) for inline in
 self.inlines]

 (Obviously, that is without filtering).

 I'm happy to submit a documentation patch, if it is likely to be 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/061.286c77d79d2997fa74ee6aeae39f7f20%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21903: Query with select_related and defer on MySQL causes id field to be returned as bool

2014-01-29 Thread Django

* component: Uncategorized => Database layer (models, ORM)
* stage: Unreviewed => Ready for checkin

Comment:

Seems like patch 9918c4ac3ec9622631558ef26ebf3919cb69 (#21413) should
be backpatched from master. I don't recall why I didn't do that
originally, maybe I just forgot to do that.

See

https://github.com/akaariai/django/compare/django:stable%2F1.6.x...ticket_21903_16
for a branch having tests for this ticket + backpatch of #21413. I think
that there isn't point in adding this ticket's tests. The backpatch has a
much simpler test case. I'll mark this RFC, but I'll wait a little bit for
possible reviewers.

As for why these bugs happen - the compiler.resolve_columns() is trying to
mimic what SELECT clause generation is doing. And, unfortunately the
SELECT clause generation is complex (caused by defer, select_related,
annotations and extra). In the long term we should probably move to
something where select setup generates a list of "col_sql, alias, field",
and then resolve_columns could just use that list.

--
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.63369ae35462749c194e35978c21f7ad%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21903: Query with select_related and defer on MySQL causes id field to be returned as bool

2014-01-29 Thread Django

#21903: Query with select_related and defer on MySQL causes id field to be 
returned
as bool
---+--
 Reporter:  matklad|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.6
 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 manfre):

 Django has had some issues with field alignment when using select_related
 and defer. See #21203. The fix was back patched to 1.6.x, but perhaps
 there has been a subsequent regression.

-- 
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.67b27ac1811016093049f0ea4aca8090%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21907: GeoQueryset.transform() broken in Spatialite >= 4

2014-01-29 Thread Django

#21907: GeoQueryset.transform() broken in Spatialite >= 4
-+-
 Reporter:  dfunckt  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  GIS  |Version:  master
 Severity:  Normal   |   Keywords:  geodjango, spatialite, geoqueryset,
 Triage Stage:   |  transform, srs, google, mercator, 900913,
  Unreviewed |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Hello, changeset
 
[https://code.djangoproject.com/changeset/362dd68fb20be195462af22448416c9895ce7df7
 #362dd68fb20] broke adding Google's 900913 SRS entry in spatialite.
 {{{django.contrib.gis.utils.add_srs_entry}}} leaves the new {{{srtext}}}
 field empty, resulting in {{{GeoQueryset.transform()}}} raising an
 OGRException exception. Here's the traceback:

 {{{
 Traceback:
 File "/src/django/django/core/handlers/base.py" in
 get_response
   113. response = wrapped_callback(request,
 *callback_args, **callback_kwargs)
 File "/views.py" in object_list
   121. .distance(location.point,
 field_name='current_location__point'))
 File "/src/django/django/contrib/gis/db/models/query.py" in
 distance
   104. return self._distance_attribute('distance', geom, **kwargs)
 File "/src/django/django/contrib/gis/db/models/query.py" in
 _distance_attribute
   648. u, unit_name, s =
 get_srid_info(self.query.transformed_srid, connection)
 File "/src/django/django/contrib/gis/db/models/fields.py" in
 get_srid_info
   40. spheroid = SpatialRefSys.get_spheroid(sr.wkt)
 File "/src/django/django/contrib/gis/db/backends/base.py" in
 get_spheroid
   323. srs = gdal.SpatialReference(wkt)
 File "/src/django/django/contrib/gis/gdal/srs.py" in __init__
   94. self.import_user_input(srs_input)
 File "/src/django/django/contrib/gis/gdal/srs.py" in
 import_user_input
   295. capi.from_user_input(self.ptr, force_bytes(user_input))
 File
 "/src/django/django/contrib/gis/gdal/prototypes/errcheck.py"
 in check_errcode
   117. check_err(result)
 File "/src/django/django/contrib/gis/gdal/error.py" in
 check_err
   53. raise e(msg)

 Exception Type: OGRException at /url
 Exception Value: Corrupt data.
 }}}

 Poking inside django.contrib.gis, I figure there are 2 ways this can be
 resolved:

 1. Add a check {{{or not self.srtext}}} at
 
[https://github.com/django/django/blob/master/django/contrib/gis/db/backends/spatialite/models.py#L61
 spatialite/models.py:61]
 2. Fix
 
[https://github.com/django/django/blob/master/django/contrib/gis/utils/srs.py#L67
 django.contrib.gis.utils.add_srs_entry] by checking the connection
 version, similar to how it's done models.py 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/050.1e4336d04b1381e5901e975d79b740a8%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19884: Inspectdb on Oracle doesn't produce correct field types

2014-01-29 Thread Django

#19884: Inspectdb on Oracle doesn't produce correct field types
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Shai Berger ):

 In [changeset:"0573120cb406066041b0235a3912dc38bc9f10ef"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0573120cb406066041b0235a3912dc38bc9f10ef"
 [1.6.x] Made Oracle introspect boolean fields

 Refs #19884

 Backport of ad975c64fc from master
 }}}

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

Re: [Django] #21903: Query with select_related and defer on MySQL causes id field to be returned as bool

2014-01-29 Thread Django

#21903: Query with select_related and defer on MySQL causes id field to be 
returned
as bool
---+--
 Reporter:  matklad|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.6
 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 russellm):

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


Comment:

 For anyone digging into this - it's possible this is a bug with
 select_related, but keep in mind that it's not out of the question that it
 might also be a… ahem… feature… of MySQL.

 See #16809 for an example of the sort of thing MySQL will do if you give
 it enough rope. Check to see if this is a problem on other databases.

-- 
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.80f59b2fa47d4dc86ccf2904ea52c6e7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19884: Inspectdb on Oracle doesn't produce correct field types

2014-01-29 Thread Django

#19884: Inspectdb on Oracle doesn't produce correct field types
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Shai Berger ):

 In [changeset:"5f42c0219550b62e62db6e0f3834671a994e3cd8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5f42c0219550b62e62db6e0f3834671a994e3cd8"
 [1.6.x] Made Oracle introspect FloatFields correctly

 Broke InspectDBTestCase.test_field_types in two:
 - a test_number_field_types, which now passes on Oracle too
 - a test_field_types, for all non-numeric fields, which is still expected
 to fail

 Also made some pep8 fixes in the tests file. Refs #19884

 Thanks Tim Graham for review.

 Backport of e9d12ba from master
 }}}

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

[django/django] 057312: [1.6.x] Made Oracle introspect boolean fields

2014-01-29 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 0573120cb406066041b0235a3912dc38bc9f10ef
  
https://github.com/django/django/commit/0573120cb406066041b0235a3912dc38bc9f10ef
  Author: Shai Berger 
  Date:   2014-01-29 (Wed, 29 Jan 2014)

  Changed paths:
M django/db/backends/oracle/introspection.py

  Log Message:
  ---
  [1.6.x] Made Oracle introspect boolean fields

Refs #19884

Backport of ad975c64fc from master


  Commit: 5f42c0219550b62e62db6e0f3834671a994e3cd8
  
https://github.com/django/django/commit/5f42c0219550b62e62db6e0f3834671a994e3cd8
  Author: Shai Berger 
  Date:   2014-01-29 (Wed, 29 Jan 2014)

  Changed paths:
M django/db/backends/oracle/introspection.py
M tests/inspectdb/tests.py

  Log Message:
  ---
  [1.6.x] Made Oracle introspect FloatFields correctly

Broke InspectDBTestCase.test_field_types in two:
- a test_number_field_types, which now passes on Oracle too
- a test_field_types, for all non-numeric fields, which is still expected to 
fail

Also made some pep8 fixes in the tests file. Refs #19884

Thanks Tim Graham for review.

Backport of e9d12ba from master


Compare: https://github.com/django/django/compare/05cef1939e52...5f42c0219550

-- 
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/52e995e689b96_44e7c55d3c175a%40hookshot-fe9-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21906: dumpdata should not use router.allow_syncdb

2014-01-29 Thread Django

#21906: dumpdata should not use router.allow_syncdb
-+-
 Reporter:  yscumc   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.5
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yscumc):

 * needs_better_patch:   => 0
 * type:  Uncategorized => Bug
 * 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/064.184fc5c30a686fccd7b29624b93fc678%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21906: dumpdata should not use router.allow_syncdb

2014-01-29 Thread Django

#21906: dumpdata should not use router.allow_syncdb
+
Reporter: yscumc | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Management commands) |Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
+
I have two databases with a router in place to prevent syncdb from
automatically creating tables on the 2nd database (referred to as:
`second_database`).

When `manage.py dumpdata --database=second_database` is executed, an empty
JSON array is printed: `[]`

Upon a lot of fumbling around, it seems that this behavior is caused by
ticket #13308 in

[[https://github.com/django/django/commit/7b47609629692241848469fabc24fa798c0ac70b|this
commit]].

{{{
if not model._meta.proxy and router.allow_syncdb(using,
model):
}}}

For the `dumpdata` command to be dependent on the `router.allow_syncdb()`
was totally unexpected because it is not documented anywhere and the name
of the router method is `allow_syncdb()` which gives the impression that
it only influences the `syncdb` command.

The `allow_syncdb` should ONLY affect `syncdb` and a separate method
should be created for the `dumpdata`/`loaddata` commands. This would allow
`dumpdata` to be run on a non-syncdb-able database.

Note: I do know there's a `Managed = False` meta option on each model and
I could remove the `allow_syncdb` on my router as a workaround for my
specific use case, but I still feel the current behavior is extremely
counter-intuitive. Either the doc should be updated, or the alternative
methods added to the router to determine the behavior for the other two
non-syncdb commands.

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

Re: [Django] #21905: Add check for default=now() on Date/Time/DateTimeFields (was: django migrate/makemigrations detects changes when none were made)

2014-01-29 Thread Django

#21905: Add check for default=now() on Date/Time/DateTimeFields
--+---
 Reporter:  taishi@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  1.7-alpha-1
 Severity:  Normal|   Resolution:
 Keywords:  check | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by MarkusH):

 * keywords:  migrate, migrations, datetime => check
 * owner:   => nobody
 * component:  Migrations => Core (Other)


Comment:

 Given the confusion about passing `default` a `datetime` object instead of
 a callable (which solves the problem), I'd like to propose the idea to add
 a check to Django's check framework to make users aware of these problems
 that might occur over the time when using `datetime.now()` instead of
 `datetime.now`.

-- 
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/083.bbdd387f3a3aac9e1cfdebfd346a9a62%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21905: django migrate/makemigrations detects changes when none were made

2014-01-29 Thread Django

#21905: django migrate/makemigrations detects changes when none were made
-+-
 Reporter:  taishi@… |Owner:
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:
 Severity:  Normal   |  1.7-alpha-1
 Keywords:  migrate, |   Resolution:
  migrations, datetime   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by taishi@…):

 matt@ comment worked

-- 
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/083.ca4c6ecf4a606f5e8fa03cc09d369fe4%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21905: django migrate/makemigrations detects changes when none were made

2014-01-29 Thread Django

#21905: django migrate/makemigrations detects changes when none were made
-+-
 Reporter:  taishi@… |Owner:
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:
 Severity:  Normal   |  1.7-alpha-1
 Keywords:  migrate, |   Resolution:
  migrations, datetime   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by MarkusH):

 * cc: info@… (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/083.45df23e0b87d8de1b08cebd622e85777%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21905: django migrate/makemigrations detects changes when none were made

2014-01-29 Thread Django

#21905: django migrate/makemigrations detects changes when none were made
-+-
 Reporter:  taishi@… |Owner:
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:
 Severity:  Normal   |  1.7-alpha-1
 Keywords:  migrate, |   Resolution:
  migrations, datetime   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by matt@…):

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


Comment:

 You don't want to be using datetime.now(): that gets evaluated at the time
 the module is imported.

 You'll want to use datetime.now

-- 
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/083.bffd0fd88942be9dfc83778898f4c68f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21905: django migrate/makemigrations detects changes when none were made

2014-01-29 Thread Django

#21905: django migrate/makemigrations detects changes when none were made
-+---
 Reporter:  taishi@… |  Owner:
 Type:  New feature  | Status:  new
Component:  Migrations   |Version:  1.7-alpha-1
 Severity:  Normal   |   Keywords:  migrate, migrations, datetime
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+---
 I'm running a model which contains datetime.now() as default value and
 django keeps thinking that I altered that field.
 So everytime I run migrates I get:
 Running migrations:
   No migrations needed.
   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.

 If I run makemigrations (once, twice, 20 times) it will always output:
 Migrations for 'acb_coins':
   0003_auto_20140129_1947.py:
 - Alter field last_sync on coin

 Model:
 class Coin(models.Model):
 name = models.CharField(max_length=80)
 short_name = models.CharField(max_length=4)
 rpc_address = models.CharField(max_length=30)
 rpc_port = models.IntegerField(max_length=5)
 balance = models.DecimalField(decimal_places=10, max_digits=15)
 last_sync = models.DateTimeField(default=datetime.now())

-- 
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.50fe0eb90a5a7505529d1320ac26c3b9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21581: collecstatic --clear is too lax about warning users

2014-01-29 Thread Django

Comment (by loic84):

@marfire I can relate to your story since this happened to me on a staging
server. I was quite grateful that my fabric task performed a `cd` to the
project folder and didn't execute `/srv/project/manage.py` from my user
directory!

The tricky part is that since [3f1c7b70537330435e2ec2fca9550f7b7fa4372e],
`STATIC_ROOT` isn't present in the `settings.py` shipped by the default
template, so it's a lot easier to forget setting it to a meaningful value,
which in turn exposes to this bug.

Hopefully we'll be able to release 1.6.2 soon enough so we can forget
about this 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/064.e8c7e67b03c653cf1227510c44dfa522%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19884: Inspectdb on Oracle doesn't produce correct field types

2014-01-29 Thread Django

#19884: Inspectdb on Oracle doesn't produce correct field types
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Description changed by shai:

Old description:

> The test inspectdb.test_field_types() has multiple errors, at least:
>   - CharField lengths not correctly inspected (returns double the length
> of generated field)
>   - FloatField not correctly inspected (returns DecimalField with
> max_digits=-127)
>   - DateTimeField is inspected as TimeField
>
> Getting all these to work correctly will be somewhat hard. So, the
> suggested short-term fix is to just mark the test as expectedFailure on
> Oracle. Inspectdb isn't high-priority as the output should be hand-edited
> in any case.

New description:

 The test inspectdb.test_field_types() has multiple errors, at least:
   - CharField lengths not correctly inspected (returns double the length
 of generated field)
   - ~~FloatField not correctly inspected (returns DecimalField with
 max_digits=-127)~~
   - DateTimeField is inspected as TimeField

 Getting all these to work correctly will be somewhat hard. So, the
 suggested short-term fix is to just mark the test as expectedFailure on
 Oracle. Inspectdb isn't high-priority as the output should be hand-edited
 in any case.

--

-- 
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.977c34a591bcf54627ed7a0ff7901055%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] e9d12b: Made Oracle introspect FloatFields correctly

2014-01-29 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e9d12bae1e59e51738c11c492c620f56f96106bf
  
https://github.com/django/django/commit/e9d12bae1e59e51738c11c492c620f56f96106bf
  Author: Shai Berger 
  Date:   2014-01-29 (Wed, 29 Jan 2014)

  Changed paths:
M django/db/backends/oracle/introspection.py
M tests/inspectdb/tests.py

  Log Message:
  ---
  Made Oracle introspect FloatFields correctly

Broke InspectDBTestCase.test_field_types in two:
- a test_number_field_types, which now passes on Oracle too
- a test_field_types, for all non-numeric fields, which is still expected to 
fail

Also made some pep8 fixes in the tests file. Refs #19884

Thanks Tim Graham for review.


-- 
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/52e983c991b18_71451089d54879d0%40hookshot-fe3-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19884: Inspectdb on Oracle doesn't produce correct field types

2014-01-29 Thread Django

#19884: Inspectdb on Oracle doesn't produce correct field types
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Shai Berger ):

 In [changeset:"e9d12bae1e59e51738c11c492c620f56f96106bf"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e9d12bae1e59e51738c11c492c620f56f96106bf"
 Made Oracle introspect FloatFields correctly

 Broke InspectDBTestCase.test_field_types in two:
 - a test_number_field_types, which now passes on Oracle too
 - a test_field_types, for all non-numeric fields, which is still expected
 to fail

 Also made some pep8 fixes in the tests file. Refs #19884

 Thanks Tim Graham for review.
 }}}

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

Re: [Django] #21904: Form clean() method should return cleaned_data in examples

2014-01-29 Thread Django

#21904: Form clean() method should return cleaned_data in examples
--+--
 Reporter:  pawel.nadolski@…  |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  Documentation |  Version:  master
 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 bmispelon):

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


Comment:

 Hi,

 See my comment in https://code.djangoproject.com/ticket/21894#comment:1

 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/082.39d68e37a3e368a6dea8c4e3bd5f4e99%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21904: Form clean() method should return cleaned_data in examples

2014-01-29 Thread Django

#21904: Form clean() method should return cleaned_data in examples
--+
 Reporter:  pawel.nadolski@…  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There is missing return statement:
 return cleaned_data
 in examples on "Form and field validation" documentation page.

 This issue is seen for development version, but is ok for 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/067.057d1e995d9f0bfc2d1645d8417b9afd%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21581: collecstatic --clear is too lax about warning users

2014-01-29 Thread Django

#21581: collecstatic --clear is too lax about warning users
-+
 Reporter:  loic84   |Owner:  loic84
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 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 marfire):

 FYI, I'm embarrassed to report that I just did this exact thing in 1.6.1
 and wiped out my entire project! Thanks to VCS I was able to recover
 easily, but, yikes. Thanks Loic for finding and fixing this.

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

Re: [Django] #21902: Document search order for list_display

2014-01-29 Thread Django

* needs_docs: => 0
* needs_better_patch: => 0
* needs_tests: => 0
* easy: 0 => 1
* stage: Unreviewed => Accepted

Comment:

Hi,

As described in the documentation [1], you can pass four different kinds
of values for `list_display`.

However, what that section doesn't say is that the given list is actually
the order in which Django tries each possibility.

I agree that it'd be useful to amend the documentation to mention
explicitly that the order of the list is the one Django uses.

As for the feature you're proposing, I don't see much value in it, for two
reasons:
1) It's already possible to override a field's display by defining a
method on the `ModelAdmin` you just need to give it a different name
2) Backwards-compatibility would be tricky

So I'm marking this ticket as `accepted` for the documentation issue
(which should be fairly trivial to fix), but I'm -0 on the proposed
change.

Thanks.

[1]

https://docs.djangoproject.com/en/1.6/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display

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

Re: [Django] #19884: Inspectdb on Oracle doesn't produce correct field types

2014-01-29 Thread Django

#19884: Inspectdb on Oracle doesn't produce correct field types
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by shai):

 I just posted [https://github.com/django/django/pull/2225/files PR 2225]
 which breaks `inspectdb.test_field_types()` in two: a
 `test_number_field_types()` which passes (the PR includes a fix to the
 !FloatField issue), and `test_field_types()` which does all the rest and
 is still marked expectedFailure; most of the fields tested there are
 !CharFields under Oracle, so fixing makes little sense indeed.

-- 
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.41442daca2f5e5ef03d72054ca83adeb%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21883: Use of xrange in custom lookups code not valid in Python 3; "__in list too long" case not tested

2014-01-29 Thread Django

#21883: Use of xrange in custom lookups code not valid in Python 3; "__in list 
too
long" case not tested
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by shai):

 Replying to [comment:1 akaariai]:
 > I don't think Python 3 + Oracle is actively tested

 Python3 + Oracle segfaults. #20725.

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

Re: [Django] #5763: Queryset doesn't have a "not equal" filter operator

2014-01-29 Thread Django

#5763: Queryset doesn't have a "not equal" filter operator
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  qs-rf|  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by PhiR_42):

 Thanks for that clarification.
 In my case it seems the patch mitigates #14645 though, so I will probably
 take my chances in production.

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

[django/django] 4e115a: [1.5.x] Fix typo CRSF -> CSRF

2014-01-29 Thread GitHub

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 4e115af105a257f3d87327d1d324a6938a504245
  
https://github.com/django/django/commit/4e115af105a257f3d87327d1d324a6938a504245
  Author: Ian Foote 
  Date:   2014-01-29 (Wed, 29 Jan 2014)

  Changed paths:
M docs/ref/contrib/csrf.txt

  Log Message:
  ---
  [1.5.x] Fix typo CRSF -> CSRF

Backport of af64f829d7 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/52e935b27cf75_bb4923d581227ea%40hookshot-fe2-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 05cef1: [1.6.x] Fix typo CRSF -> CSRF

2014-01-29 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 05cef1939e523bdd80d3d3f7864c3b89a2cab303
  
https://github.com/django/django/commit/05cef1939e523bdd80d3d3f7864c3b89a2cab303
  Author: Ian Foote 
  Date:   2014-01-29 (Wed, 29 Jan 2014)

  Changed paths:
M docs/ref/contrib/csrf.txt

  Log Message:
  ---
  [1.6.x] Fix typo CRSF -> CSRF

Backport of af64f829d7 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/52e935b5a026d_588a929d3455042%40hookshot-fe9-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21903: Query with select_related and defer on MySQL causes id field to be returned as bool

2014-01-29 Thread Django

#21903: Query with select_related and defer on MySQL causes id field to be 
returned
as bool
---+
 Reporter:  matklad|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I selected an object `obj` by a query with select_related and defer, to
 find out that `obj.user.id` is `True` instead of `1`. Technically, `True
 == 1`, but it doesn't work with, for example, url reversing. I managed to
 reproduce this behaviour on MySQL, python2 and python3. With SQLite I get
 `1` as expected. Here is a test case that show this surprising behaviour:

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

 class A(models.Model):
 dspam = models.TextField()
 eggs = models.BooleanField(default=False)

 class B(models.Model):
 a = models.ForeignKey(A)

 class C(models.Model):
 b = models.ForeignKey(B)

 class D(models.Model):
 c = models.ForeignKey(C)
 dfoo = models.TextField()
 dbar = models.TextField()

 user = models.ForeignKey(settings.AUTH_USER_MODEL, null=True)
 time = models.DateTimeField(null=True)

 class E(models.Model):
 d = models.ForeignKey(D)
 dbaz = models.TextField()
 }}}
 test.py
 {{{
 from django.contrib.auth.models import User
 from django.test import TestCase
 from .models import *

 class Test(TestCase):
 def setUp(self):
 self.a = A.objects.create()
 self.b = B.objects.create(a=self.a)
 self.c = C.objects.create(b=self.b)
 self.user = User.objects.create_user("foo", "foo@example.com",
 password="424242", id=1)
 self.d = D.objects.create(c=self.c, user=self.user)
 self.e = E.objects.create(d=self.d)

 def test(self):
 qs = (E.objects
   .select_related('d__user', 'd__c__b__a')
   .filter(d__c__b=self.b, d__user_id=1)
   .defer('dbaz', 'd__dfoo', 'd__dbar',
  'd__c__b__a__dspam'))
 user = qs[0].d.user
 print(user.id)  # prints True. Technically it is an Int, but bools
 don't work with, for example, url reversing
 }}}

 pip freeze

 {{{
 Django==1.6.1
 MySQL-python==1.2.5
 wsgiref==0.1.2
 }}}

-- 
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.39ea66720fe8a448784ed6608c5a4723%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] af64f8: Fix typo CRSF -> CSRF

2014-01-29 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: af64f829d7b9179ebda0033cef5f0c0d9dd73079
  
https://github.com/django/django/commit/af64f829d7b9179ebda0033cef5f0c0d9dd73079
  Author: Ian Foote 
  Date:   2014-01-29 (Wed, 29 Jan 2014)

  Changed paths:
M docs/ref/contrib/csrf.txt

  Log Message:
  ---
  Fix typo CRSF -> CSRF


  Commit: 1ed02843abe74a188bb7f9bc984e52ef63ae9a1f
  
https://github.com/django/django/commit/1ed02843abe74a188bb7f9bc984e52ef63ae9a1f
  Author: Alex Gaynor 
  Date:   2014-01-29 (Wed, 29 Jan 2014)

  Changed paths:
M docs/ref/contrib/csrf.txt

  Log Message:
  ---
  Merge pull request #2224 from Ian-Foote/patch-1

Fix typo CRSF -> CSRF


Compare: https://github.com/django/django/compare/ad975c64fcdf...1ed02843abe7

-- 
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/52e932feda305_7621609d481033ec%40hookshot-fe4-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21901: Dependencies on unmigrated apps not always detected.

2014-01-29 Thread Django

#21901: Dependencies on unmigrated apps not always detected.
-+---
 Reporter:  mjtamlyn |Owner:
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7-alpha-1
 Severity:  Release blocker  |   Resolution:  duplicate
 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 bmispelon):

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


Comment:

 The same user who posted this comment also opened a ticket: #21872.

 It should be fixed now. Do you still see this error on master?

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

[Django] #21902: Document search order for list_display

2014-01-29 Thread Django

#21902: Document search order for list_display
---+
 Reporter:  schrinaw@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.5
 Severity:  Normal |   Keywords:  admin
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Suppose I have a ModelAdmin with `list_display =
 ["some","model","fields"]` but then I also want to override how one of
 those fields is displayed, so I create a method on the ModelAdmin Class
 {{{
 def some(self, obj):
 return "blah"
 }}}

 It seems the model field takes precedence over the method on the
 ModelAdmin, and I don't see "blah" returned in the changelist.  This is
 not clear from the documentation.  (I figured I would be able to override
 it).

 On a related note, I think it makes sense to be able to override it in the
 ModelAdmin.

-- 
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/061.338f68873becabba54deac61c3bade03%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ad975c: Made Oracle introspect boolean fields

2014-01-29 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ad975c64fcdf3faa67cacd51665c4f95a2c5b060
  
https://github.com/django/django/commit/ad975c64fcdf3faa67cacd51665c4f95a2c5b060
  Author: Shai Berger 
  Date:   2014-01-29 (Wed, 29 Jan 2014)

  Changed paths:
M django/db/backends/oracle/introspection.py

  Log Message:
  ---
  Made Oracle introspect boolean fields

Fixed failing test schema.tests.SchemaTests.test_add_field_temp_default_boolean
Refs #19884


-- 
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/52e928043c4bc_3d89aebd34514d9%40hookshot-fe8-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19884: Inspectdb on Oracle doesn't produce correct field types

2014-01-29 Thread Django

#19884: Inspectdb on Oracle doesn't produce correct field types
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Shai Berger ):

 In [changeset:"ad975c64fcdf3faa67cacd51665c4f95a2c5b060"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ad975c64fcdf3faa67cacd51665c4f95a2c5b060"
 Made Oracle introspect boolean fields

 Fixed failing test
 schema.tests.SchemaTests.test_add_field_temp_default_boolean
 Refs #19884
 }}}

-- 
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.87bd4983f24a6f2fce0bfd6d397db939%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21901: Dependencies on unmigrated apps not always detected.

2014-01-29 Thread Django

https://github.com/django/django/commit/941d23e54890bcc9e73734c5c1f3c82193fd97d6

I have seen this behaviour myself, with a custom user model using
`PermissionsMixin`. The necessary line in `dependencies` of `("auth",
"__first__"),` is not present. I'm not sure whether this is an issue with
it being a swappable model or not, but there's definitely a bug anyway.

The migration gets written out, but on running it you get a traceback
because the relations to auth cannot resolve (as the migration's limited
app cache ignores auth)

--
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.04895b445c8a50f5a75e4de80d1d1800%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21900: Medication for erectile dysfunction has in fact proven to be so successful in improving health in scientific research that Dr

2014-01-29 Thread Django

#21900: Medication for erectile dysfunction has in fact proven to be so
successful
in improving health in scientific research that Dr
---+---
Reporter: anonymous | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized |Version: 1.6
Severity: Normal | Keywords: MUSCLE REV XTREME
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+---
It may look equivalent every example you motion on the tuner or the video
that you are existence bombarded with yet another ad for erectile
pathology (ED). When you are handling with a precondition as sticky as ED,
these ads may fit be the end entity you deprivation to concentrate. But
you may poorness to select whatever status in the fact that ED medicament
is beingness so widely advertised. Why do you imply that is? This is
because of the fact that ED is a really thoughtful job that affects one in
figure Earth men every lonesome day. That's sect, organism dealings with
the one artefact you are dealing with. And the present that ED medicament
is so widely advertised is because ED is not vindicatory a extraordinary
upbeat difficulty, in fact, ED is ofttimes enough a house of whatever
other real implicit stipulation. Here we will address why ED drug is so
eventful, and how you can secondary your eudaemonia risks, AND plow your
erectile pathology with a kinda dolabriform handling counsel. MUSCLE REV
XTREME

Studies on pharmaceutical companies express that the most touristy
grouping of take classes is the medication separate familiar as expansive
dysfunction medicament. This gather of drug is e'er making tidings for a
represent. It entireness! Regrettably, men that are dealing with ED do not
oft examine the whim that ED is not their exclusive problem. Time it can
seem equal ED is the large problem in your time, it is influential to get
treated for ED because in some cases, ED is a symptom of an implicit
medical condition, and not ever the only job in itself.
Studies conducted at the University Medical Refer in City, Frg by a Dr.
Frank Sommer suggest that drug for ED entirety to not only modify
execution travel to the member, sanctioning an erection, but these
medications also target else welfare issues. Cardiovascular serve for
representative is oftentimes one of the initial compromised systems, and
ED can be a symptom of pinched cardio function in a man. Explore upcoming
out of Cologne, Deutschland shows us that not only does ED drug supply ED
healthy, but it also lowers your peril of courageousness disease and added
improves your endocrine duty. For men that are considering ED drug such as
Levitra, it is cheering to deed technological search indicating that this
medication give not only amend your ED difficulty, bu MUSCLE REV XTREME

Medication for expansive dysfunction has in fact proven to be so
prosperous in improving eudaemonia in technological explore that Dr.
Sommer is suggesting that penalty suchlike Levitra beautify famed not
fitting as an ED drug, but a "men's upbeat tab" all unitedly. Though these
findings are only preliminary, they are stiff sufficiency to feigning us
that erectile dysfunction is not just a one pronged problem. If you are
suffering from erectile pathology, it can be rattling wanton to seek
similar this is the large problem you hump ever old. But it is valuable to
see that ED may be only a symptom of a often bigger difficulty at bay. At
the gear signs of ED, sex sprightliness, but this handling is around
improving your character of animation boilersuit.
[http://trymusclerevxtremes.com/]

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

Re: [Django] #5763: Queryset doesn't have a "not equal" filter operator

2014-01-29 Thread Django

Comment (by akaariai):

Be warned - not using subqueries might actually produce incorrect results.
Specifically, .exclude() guarantees that you get the complement of what
you get with .filter(). There are cases where `field__ne` will not produce
the complement of `field__exact`. This happens for example if the field
has NULL values. Both `__exact` and `__ne` will miss such rows, as in SQL
terms both 'val = NULL' and 'val != NULL' have unknown result.

As mjtamlyn noted a `__ne` lookup will be fairly straightforward to
implement in 1.7. Check https://docs.djangoproject.com/en/dev/ref/models
/custom-lookups/ for details.

--
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.71f3d78418ccc186822554f4ef4aa5ac%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5763: Queryset doesn't have a "not equal" filter operator

2014-01-29 Thread Django

#5763: Queryset doesn't have a "not equal" filter operator
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  qs-rf|  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by mjtamlyn):

 It is worth noting that in 1.7 this can be written as a custom lookup if
 you need it. I think it might even be the example in the docs.

-- 
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.808a8ecf3f4f3638f83e0bbe3703a236%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5763: Queryset doesn't have a "not equal" filter operator

2014-01-29 Thread Django

#5763: Queryset doesn't have a "not equal" filter operator
-+-
 Reporter:  jdetaeye |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  qs-rf|  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by PhiR_42):

 Just for the record, this is very important for a specific use case: when
 you want to add extra select columns from the joined tables. I have an
 ORM-based search form and using exclude will break in many cases because
 it uses more subqueries. Using filter(related__field__ne = something) will
 work as expected while exclude(related__field = something) will generate a
 subquery and remove the possibility of selecting tables.

-- 
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.5d1db988319585157f311f6f49b39ac2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21899: Reverse does not work with function and namespace

2014-01-29 Thread Django

#21899: Reverse does not work with function and namespace
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by tonnzor):

 Since Django always state that I could use function instead of its name
 for routing (i.e. in urls.py, reverse and redirect) -- I assume it is a
 bug that it cannot be used in combination with namespace. Not
 documentation 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.26f72c50d234d613e9ab3593cc668ed9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21899: Reverse does not work with function and namespace

2014-01-29 Thread Django

#21899: Reverse does not work with function and namespace
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by tonnzor):

 But how could I reverse my view by function when using namespace?

 Then why do we need current_app if it is not able to find view by it?

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

Re: [Django] #21899: Reverse does not work with function and namespace

2014-01-29 Thread Django

#21899: Reverse does not work with function and namespace
-+-
 Reporter:  tonnzor  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mjtamlyn):

 * type:  Bug => Cleanup/optimization
 * component:  Core (URLs) => Documentation


Comment:

 Namespaces are designed to be used with URL names, which is a much better
 way of reversing anyway. I don't think this should be changed, but perhaps
 docs could be clarified?

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

Re: [Django] #21826: Forgot your password? "page unavailable"

2014-01-29 Thread Django

#21826: Forgot your password? "page unavailable"
-+
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  *.djangoproject.com  |  Version:  1.6
 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
-+

Comment (by bmispelon):

 FYI the fix got deployed today so everything should be back to normal now.

-- 
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.929d26aa268b10c2202e7cf6c879f9de%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11978: 'Duplicate key value violates unique constraint' error while changing inline admin model

2014-01-29 Thread Django

#11978: 'Duplicate key value violates unique constraint' error while changing
inline admin model
---+--
 Reporter:  kozlenko   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  1.1
 Severity:  Normal |   Resolution:  invalid
 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 ivanov.george.bogdan@…):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Can you please share your solution?

-- 
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.7975f33760f7f64193d90871fe08c849%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21895: Probably erroneous documentation about new contrib.admin and admin.autodiscover

2014-01-29 Thread Django

#21895: Probably erroneous documentation about new contrib.admin and
admin.autodiscover
---+---
 Reporter:  claus  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.7-alpha-1
 Severity:  Normal |   Resolution:  worksforme
 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 claus):

 I see - 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/063.d680ab2012d6c45662392cae8a3e789b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21899: Reverse does not work with function and namespace

2014-01-29 Thread Django

#21899: Reverse does not work with function and namespace
-+--
 Reporter:  tonnzor  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.4
 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 tonnzor):

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


Comment:

 If you use view functions in '''payment/urls.py''' -- it works exactly the
 same.


 '''payment/urls.py''':
 {{{
 from django.conf.urls.defaults import *
 from payment.views import *

 urlpatterns = patterns('',
 url(r'^paypal_express/confirm/$', paypal_express_confirm),
 )
 }}}

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

[Django] #21899: Reverse does not work with function and namespace

2014-01-29 Thread Django

#21899: Reverse does not work with function and namespace
-+
 Reporter:  tonnzor  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (URLs)  |Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 '''django.core.urlresolvers.reverse''' does not work with function and
 namespace.

 Example:

 {{{
 >>> from payment.views import *
 >>> reverse('payment:payment.views.paypal_express_confirm') # resolve
 using namespace and view path
 '/payment/paypal_express/confirm/'

 >>> paypal_express_confirm # check function is there
 

 >>> reverse(paypal_express_confirm) # try direct resolve
 Traceback (most recent call last):
   File "", line 1, in 
   File "django/core/urlresolvers.py", line 476, in reverse
 return iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args,
 **kwargs))
   File "django/core/urlresolvers.py", line 396, in _reverse_with_prefix
 "arguments '%s' not found." % (lookup_view_s, args, kwargs))
 NoReverseMatch: Reverse for 'payment.views.paypal_express_confirm' with
 arguments '()' and keyword arguments '{}' not found.

 >>> reverse(paypal_express_confirm, current_app='payment') # try with
 current_app given
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/tonnzor/projects/reelport-
 application/picturepipe/src/django/django/core/urlresolvers.py", line 476,
 in reverse
 return iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args,
 **kwargs))
   File "/home/tonnzor/projects/reelport-
 application/picturepipe/src/django/django/core/urlresolvers.py", line 396,
 in _reverse_with_prefix
 "arguments '%s' not found." % (lookup_view_s, args, kwargs))
 NoReverseMatch: Reverse for 'payment.views.paypal_express_confirm' with
 arguments '()' and keyword arguments '{}' not found.

 >>> reverse(paypal_express_confirm, urlconf='payment.urls') # try app urls
 without namespaces or something
 '/paypal_express/confirm/'
 }}}

 Sure it works when you open '''/payment/paypal_express/confirm/'''

 My project:

 '''/urls.py:'''

 {{{
 from django.conf.urls import *

 urlpatterns = patterns('',
 url(r'^payment/', include('payment.urls', namespace='payment',
 app_name='payment')),
 )
 }}}

 '''payment/urls.py:'''
 {{{
 from django.conf.urls.defaults import *

 urlpatterns = patterns('payment.views',
 url(r'^paypal_express/confirm/$', 'paypal_express_confirm'),
 )
 }}}

 '''payment/views.py:'''
 {{{
 from django.http import HttpResponse

 def paypal_express_confirm(request):
 return HttpResponse('Confirm')

 }}}

 Sorry, I didn't get hands to test on master -- but I'm pretty sure it is
 still there.

-- 
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.392782bc7e1ac70884370722ffd7b193%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

2014-01-29 Thread Django

#15089: contrib.sites and multitenancy
---+
 Reporter:  legutierr  |Owner:  apollo13
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:
 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 simonkagwe):

 * cc: simonkagwe (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/067.d5fee8431c33e98ef8f94fb2967a275f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21898: SingleObjectMixin should not require slug or pk if queryset is given

2014-01-29 Thread Django

#21898: SingleObjectMixin should not require slug or pk if queryset is given
--+
 Reporter:  tomc  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Generic views |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I might be missing an obvious design decision made here, but it seems to
 me that if you give a queryset or define get_queryset() in a class with
 the SingleObjectMixin, that I shouldn't need to override get_object() and
 essentially dump the same code in but without checking for slug or pk.

 Simple use case: I'm rolling my own flatpages style app, different enough
 that I don't want to inherit from it. I'm not using the url as the pk as
 if someone typos the url the first time, they end up with two pages if
 they rename it. So my code ends up looking like this:


 {{{
 class PageDetail(DetailView):
 def get_queryset(self):
 return Page.objects.filter(url=self.kwargs.get('url'))

 def get_object(self, queryset=None):
 if queryset is None:
 queryset = self.get_queryset()

 try:
 obj = queryset.get()
 except ObjectDoesNotExist:
 raise Http404('No %(verbose_name)s found matching the query' %
   {'verbose_name':
 queryset.model._meta.verbose_name})

 return obj

 def get_template_names(self):
 return [self.object.template_name]
 }}}

 I feel like I should be able to just set the queryset without overriding
 get_object()

 Another option instead of removing the pk or slug check, might be to have
 a variable that sets the lookup field that can be anything, not just slug
 or pk, and if this isn't set, it reverts to the current behaviour

 I should be able to provide a patch for either case if necessary.

-- 
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/047.0853d45f5cecb09740e14847beb43051%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21895: Probably erroneous documentation about new contrib.admin and admin.autodiscover

2014-01-29 Thread Django

#21895: Probably erroneous documentation about new contrib.admin and
admin.autodiscover
---+---
 Reporter:  claus  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.7-alpha-1
 Severity:  Normal |   Resolution:  worksforme
 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 mjtamlyn):

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


Comment:

 This is an issue with 1.7alpha1 compared to current master. For the alpha,
 you would need `django.contrib.admin.apps.AdminConfig`, but in master you
 will not.

-- 
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/063.ec33b0088ed8ff3a857fc1610b0d3749%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21897: Reset password of djangoproject.com is broken

2014-01-29 Thread Django

#21897: Reset password of djangoproject.com is broken
-+-
 Reporter:  Reza Mohammadi   |Owner:  nobody
 |   Status:  closed
 Type:  Bug  |  Version:
Component:  *.djangoproject.com  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

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


Comment:

 Hi,

 This has been reported in #21826. We have a fix for it but we're running
 into issues with the deployment.

 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/089.98ab15e5aabd00b1256ae29512328db9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21897: Reset password of djangoproject.com is broken

2014-01-29 Thread Django

#21897: Reset password of djangoproject.com is broken
-+
 Reporter:  Reza Mohammadi   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  *.djangoproject.com  |Version:
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Using chrome and firefox on Mac, during the past few days every time I
 tried to start recovering my password through
 https://www.djangoproject.com/accounts/password/reset/, I got the
 following error on visiting(GET) the page:

 Page unavailable
 We're sorry, but the requested page is currently unavailable.
 We're messing around with things internally, and the server had a bit
 of a hiccup.
 Please try again 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/074.f62c6f5cf54de8b6abee98d6eac2f1d2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21896: makemigrations warning "trying to add a non-nullable field" is raised even when the table is empty

2014-01-29 Thread Django

#21896: makemigrations warning "trying to add a non-nullable field" is raised 
even
when the table is empty
--+-
 Reporter:  kunitoki  |  Owner:
 Type:  Cleanup/optimization  | Status:  new
Component:  Migrations|Version:  1.7-alpha-1
 Severity:  Normal|   Keywords:  migrations
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Probably doing a count() on the table would save a warning and user
 interaction.

-- 
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.750b7db11b182a4d09455929c5b3ab9b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21895: Probably erroneous documentation about new contrib.admin and admin.autodiscover

2014-01-29 Thread Django

#21895: Probably erroneous documentation about new contrib.admin and
admin.autodiscover
---+-
Reporter: claus | Owner: nobody
Type: Bug| Status: new
Component: Documentation |Version: 1.7-alpha-1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+-
After upgrading a project from 1.6.1 to 1.7a1 I removed the call to
''autodiscover()'' from my URLconf, as indicated by
[https://docs.djangoproject.com/en/dev/releases/1.7/#app-loading-refactor
this section] in the release notes:

{{{
The admin automatically calls autodiscover() when Django starts. You can
consequently remove this line from your URLconf.
}}}

This does not work in my upgraded application; without the call to
autodiscover superusers don't have any permissions in the admin interface.
In case the above paragraph only applies to apps created using 1.7a1, then
mentioning the removal of code seems at least ambiguous.

[https://docs.djangoproject.com/en/dev/releases/1.7/#start-up-sequence
Later on] the release notes read:

{{{
django.contrib.admin will now automatically perform autodiscovery of admin
modules in installed applications. To prevent it, change your
INSTALLED_APPS to contain 'django.contrib.admin.apps.SimpleAdminConfig'
instead of 'django.contrib.admin'.
}}}

I am not sure if this is correct, after reading some posts on the
developers list about this it seems to me that ''django.contrib.admin''
should read ''django.contrib.admin.apps.AdminConfig'' here, if one wants
to rely on autodiscovery - unfortunately I haven't had time to try this in
my code yet.

--
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/048.d2fae3cf2e25903eb0e9498b9eb5f573%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21894: Error in example code in django.forms.Form.clean()¶

2014-01-29 Thread Django

#21894: Error in example code in django.forms.Form.clean()¶
---+--
 Reporter:  richard.kellner@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  worksforme
 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 bmispelon):

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


Comment:

 Hi,

 The documentation is correct: this is a new feature in the development
 version of Django (soon-to-be 1.7), as described by the note under the
 example:

 > In previous versions of Django, form.clean() was required to return a
 dictionary of cleaned_data. This method may still return a dictionary of
 data to be used, but it’s no longer 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/086.b6c23401e1d3cfa144951816db3aabc9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21894: Error in example code in django.forms.Form.clean()¶

2014-01-29 Thread Django

#21894: Error in example code in django.forms.Form.clean()¶
---+
 Reporter:  richard.kellner@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In Documentation version: development explanation of Cleaning and
 validating fields
 (https://docs.djangoproject.com/en/dev/ref/forms/validation/#cleaning-and-
 validating-fields-that-depend-on-each-other) that depend on each other
 there is and error. Code in the sample would thow an exeptoion: TypeError:
 argument of type 'NoneType' is not iterable because function does not
 return anything back. Documentation in 1.6 is correct and does not have
 this error. To resolve add return statement at the end of both function in
 example:

 {{{
 # Always return the full collection of cleaned data.
 return cleaned_data
 }}}

-- 
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.2ae9cf59ceccb98bde5714ec6dc6a228%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

56 matches

Mail list logo