Re: [Django] #24289: Is usage of many_to_one and one_to_many terms confusing for relation flags?

[Django]

#24289: Is usage of many_to_one and one_to_many terms confusing for relation 
flags?
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   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 loic):

 From my understanding historically `Field.rel` meant "relation", not
 "related field". This only changed with #21414 where we replaced
 `RelatedObject` by `*Rel` objects and the meta refactor that made these
 show up in `get_fields()`.

 So if anything I find that `isinstance(ForeignKey.rel, ManyToOneRel) ==
 True` is consistent with `ForeignKey.many_to_one == True`.

 Also I wouldn't get to hung up on the naming of `*Rel` or `*Descriptor`
 objects, naming of things in `related.py` is extremely confusing and
 inconsistent.

 I'm really +1 on swapping them, the "to" from `ForeignKey(to=Company)`
 should mean the same thing as the "to" from "ForeignKey.many_to_one" IMO.

 I really don't like `has_many` (it was initially part of the meta
 refactor) specifically because of fields like `ArrayField`.

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

Re: [Django] #24289: Is usage of many_to_one and one_to_many terms confusing for relation flags?

[Django]

#24289: Is usage of many_to_one and one_to_many terms confusing for relation 
flags?
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   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 akaariai):

 I don't think reversing the many_to_one and one_to_many definitions will
 help. The terms are confusing, no matter which way they are used, and I
 believe the terms are used the correct way (as in, the most often seen
 definition)

 I see two ways forward:
   - Keep the flags as is. Maybe add a bit more documentation somewhere
 that tell explicitly what these flags mean in Django.
   - Use some other flags for relations. A possibility is local_multiple
 and remote_multiple flags. These flags would tell if a single object can
 have multiple objects. remote_multiple tells that the local object can
 have multiple objects on the remote side. local_multiple is the opposite:
 can a single remote object have multiple objects on the local side. Still
 a bit confusing, but I think these are easier to recall correctly.

 A bonus of the second approach is that I believe the local_multiple and
 remote_multiple properties are what we are most often interested about: we
 can select_related if the relation is remote_multiple=False. We need to
 use subqueries with .exclude() when the relation is remote_multiple=True.
 The widget in forms is SelectMultiple when remote_multiple=True.

 We could also use just a has_many flag, but then it's hard to say if an
 ArrayField should have has_many set. The remote_multiple is better, as it
 is explicitly about relations.

 We could even have both n_to_n flags, and the local_multiple and
 remote_multiple flags. We could use the checks framework to warn if the
 flags aren't defined in a consistent way.

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

Re: [Django] #24215: Refactor of lazy model operations

[Django]

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by AlexHill):

 PR now in much better shape thanks to review from Collin, Anssi, Simon and
 Carl. Notably:
 * I'm no longer using the `class_prepared` signal. Instead,
 `Apps.do_pending_lookups` is called directly at the end of
 `Apps.register_model`.
 * `Apps.lazy_model_operation` no longer accepts keyword arguments.
 Functions passed to it should expect a number of models as positional
 arguments, and nothing else.
 * The `lazy_related_operation` convenience wrapper still supports keyword
 arguments, but they're applied to the supplied function with `partial`
 before it's passed to `Apps.lazy_model_operation`.

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

Re: [Django] #24282: Cannot Modify Foreign Keys Within Data Migrations

[Django]

#24282: Cannot Modify Foreign Keys Within Data Migrations
-+-
 Reporter:  jeffasinger  |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   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 jeffasinger):

 Still fails unfortunately when tested against that patch.

 I am having trouble creating a failing test case though. The PR definitely
 seems related.

 Here's a few things I've noticed since today:

 1. It's not actually a ForeignKey, but the forward end of a OneToOneField.
 I'm doubting that matters, but I figured I'd throw that out there.
 2. The repr of type(a) and field.rel.to are the same, however, the id of
 them is not the same.
 3. The id of type(a) is the same as the one in the apps.all_models
 dictionary.
 4. Stepping through several migrations of the same app, the id(type(a)) is
 different each time, which makes sense, as the model is changing. However,
 id(field.rel.to) does not match the current version of a, but one from a
 previous migration.

 Hope that helps a little bit, in the mean time, I'll keep trying to get a
 testcase that reproduces 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/069.9087aad61a0e3456fd5ad711529e845e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24289: Is usage of many_to_one and one_to_many terms confusing for relation flags?

[Django]

#24289: Is usage of many_to_one and one_to_many terms confusing for relation 
flags?
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   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 collinanderson):

 * cc: cmawebsite@… (added)


Comment:

 I believe the precedent that Russ is talking about is `ManyToOneRel` (ie
 `author.book_set`), which I also think should be a one_to_many.

 ForeignKeys are One-to-many, based on the interpretation that there is
 "one" value on the side that defines them, and "many" on the other side.

 The UI for this is a dropdown where for a book, you choose (one) of
 "many" (possible) authors. However, once the value is chosen and the
 relationship is set, there's only one author.

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

Re: [Django] #24311: Foreign key constraint error when syncing unmigrated models that relate to migrated models

[Django]

#24311: Foreign key constraint error when syncing unmigrated models that relate 
to
migrated models
-+--
 Reporter:  collinanderson   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   Resolution:  wontfix
 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 collinanderson):

 Cool. Thanks for looking into 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/072.9117dcb32207f91abc86371d77d5fc2c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24325: Cannot reference FK relation from inline ModelForm.save()

[Django]

#24325: Cannot reference FK relation from inline ModelForm.save()
--+-
 Reporter:  Starou|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.8alpha1
 Severity:  Release blocker   |   Resolution:
 Keywords:  inline ModelForm  | 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):

 * severity:  Normal => Release blocker


Comment:

 This might need to be documented on a backwards incompatible change, but I
 haven't fully investigated the 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/064.e50a6ef2ad32b71c4d3880e0372faf5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24282: Cannot Modify Foreign Keys Within Data Migrations

[Django]

#24282: Cannot Modify Foreign Keys Within Data Migrations
-+-
 Reporter:  jeffasinger  |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   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):

 Jeff, could you test with the patch from
 [https://github.com/django/django/pull/4097 PR 4097] and see if that
 solves 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/069.cfca9f58c50b91c3012a35cadf4f9094%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24215: Refactor of lazy model operations

[Django]

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #24335: DateRange and friends require psycopg2 >= 2.5

[Django]

#24335: DateRange and friends require psycopg2 >= 2.5
-+-
 Reporter:  claudep  |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.postgres |  Version:  1.8alpha1
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-beta | 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):

 * cc: mjtamlyn (added)
 * keywords:   => 1.8-beta
 * 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/065.7557751cea2b65f6c0fac43881f9a31a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24311: Foreign key constraint error when syncing unmigrated models that relate to migrated models

[Django]

#24311: Foreign key constraint error when syncing unmigrated models that relate 
to
migrated models
-+--
 Reporter:  collinanderson   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   Resolution:  wontfix
 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 MarkusH):

 Hint: the constraints to e.g. `auth_group` are created if `auth` has been
 migrated before:

 {{{#!bash
 $ python manage.py migrate auth
 $ python manage.py migrate
 $ echo "SHOW CREATE TABLE app_myuser_groups;" | mysql -u django -p django
 Enter password:
 Table   Create Table
 app_myuser_groups   CREATE TABLE `app_myuser_groups` (\n  `id` int(11)
 NOT NULL AUTO_INCREMENT,\n  `myuser_id` int(11) NOT NULL,\n  `group_id`
 int(11) NOT NULL,\n  PRIMARY KEY (`id`),\n  UNIQUE KEY `myuser_id`
 (`myuser_id`,`group_id`),\n  KEY `app_myuser_groups_f1d9e869`
 (`myuser_id`),\n  KEY `app_myuser_groups_5f412f9a` (`group_id`),\n
 CONSTRAINT `group_id_refs_id_58abbaa5` FOREIGN KEY (`group_id`) REFERENCES
 `auth_group` (`id`),\n  CONSTRAINT `myuser_id_refs_id_08272aba` FOREIGN
 KEY (`myuser_id`) REFERENCES `app_myuser` (`id`)\n) ENGINE=InnoDB DEFAULT
 CHARSET=utf8
 }}}

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

Re: [Django] #24334: auth admin password reset doesn't work with non-digit custom user PK

[Django]

#24334: auth admin password reset doesn't work with non-digit custom user PK
--+-
 Reporter:  timgraham |Owner:  timgraham
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.8alpha1
 Severity:  Normal|   Resolution:
 Keywords:  1.8-beta  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by timgraham):

 * keywords:   => 1.8-beta


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

Re: [Django] #24311: Foreign key constraint error when syncing unmigrated models that relate to migrated models

[Django]

#24311: Foreign key constraint error when syncing unmigrated models that relate 
to
migrated models
-+--
 Reporter:  collinanderson   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   Resolution:  wontfix
 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 MarkusH):

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


Comment:

 On 1.8 this is the SQL run by the syncdb code (last query fails):

 {{{#!sql
 CREATE TABLE `app_myuser` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY
 KEY, `password` varchar(128) NOT NULL, `last_login` datetime(6) NULL,
 `is_superuser` bool NOT NULL, `username` varchar(30) NOT NULL UNIQUE,
 `first_name` varchar(30) NOT NULL, `last_name` varchar(30) NOT NULL,
 `email` varchar(254) NOT NULL, `is_staff` bool NOT NULL, `is_active` bool
 NOT NULL, `date_joined` datetime(6) NOT NULL) None
 SELECT engine FROM information_schema.tables WHERE table_name = %s
 ['app_myuser']
 CREATE TABLE `app_myuser_groups` (`id` integer AUTO_INCREMENT NOT NULL
 PRIMARY KEY, `myuser_id` integer NOT NULL, `group_id` integer NOT NULL,
 UNIQUE (`myuser_id`, `group_id`)) None
 SELECT engine FROM information_schema.tables WHERE table_name = %s
 ['app_myuser_groups']
 CREATE TABLE `app_myuser_user_permissions` (`id` integer AUTO_INCREMENT
 NOT NULL PRIMARY KEY, `myuser_id` integer NOT NULL, `permission_id`
 integer NOT NULL, UNIQUE (`myuser_id`, `permission_id`)) None
 SELECT engine FROM information_schema.tables WHERE table_name = %s
 ['app_myuser_user_permissions']
 Running deferred SQL...
 ALTER TABLE `app_myuser_groups` ADD CONSTRAINT
 `app_myuser_groups_myuser_id_2b41e8461df0328_fk_app_myuser_id` FOREIGN KEY
 (`myuser_id`) REFERENCES `app_myuser` (`id`) None
 ALTER TABLE `app_myuser_groups` ADD CONSTRAINT
 `app_myuser_groups_group_id_7a5f5bcafc6997d9_fk_auth_group_id` FOREIGN KEY
 (`group_id`) REFERENCES `au
 }}}

 On 1.7 the respective SQL is the following (no failures):

 {{{#!sql
 CREATE TABLE `app_myuser_groups` (`id` integer AUTO_INCREMENT NOT NULL
 PRIMARY KEY, `myuser_id` integer NOT NULL, `group_id` integer NOT NULL,
 UNIQUE (`myuser_id`, `group_id`)); None
 CREATE TABLE `app_myuser_user_permissions` (`id` integer AUTO_INCREMENT
 NOT NULL PRIMARY KEY, `myuser_id` integer NOT NULL, `permission_id`
 integer NOT NULL, UNIQUE (`myuser_id`, `permission_id`)); None
 CREATE TABLE `app_myuser` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY
 KEY, `password` varchar(128) NOT NULL, `last_login` datetime NOT NULL,
 `is_superuser` bool NOT NULL, `username` varchar(30) NOT NULL UNIQUE,
 `first_name` varchar(30) NOT NULL, `last_name` varchar(30) NOT NULL,
 `email` varchar(75) NOT NULL, `is_staff` bool NOT NULL, `is_active` bool
 NOT NULL, `date_joined` datetime NOT NULL); None
 ALTER TABLE `app_myuser_groups` ADD CONSTRAINT
 `myuser_id_refs_id_08272aba` FOREIGN KEY (`myuser_id`) REFERENCES
 `app_myuser` (`id`); None
 ALTER TABLE `app_myuser_user_permissions` ADD CONSTRAINT
 `myuser_id_refs_id_becb7d62` FOREIGN KEY (`myuser_id`) REFERENCES
 `app_myuser` (`id`); None
 CREATE INDEX `app_myuser_groups_f1d9e869` ON `app_myuser_groups`
 (`myuser_id`); None
 CREATE INDEX `app_myuser_groups_5f412f9a` ON `app_myuser_groups`
 (`group_id`); None
 CREATE INDEX `app_myuser_user_permissions_f1d9e869` ON
 `app_myuser_user_permissions` (`myuser_id`); None
 CREATE INDEX `app_myuser_user_permissions_83d7f98b` ON
 `app_myuser_user_permissions` (`permission_id`); None
 }}}

 However, looking at the constraints for `app_myuser_groups` this reveals a
 missing constraint to `auth_group`.

 {{{#!sql
 CREATE TABLE `app_myuser_groups` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `myuser_id` int(11) NOT NULL,
   `group_id` int(11) NOT NULL,
   PRIMARY KEY (`id`),
   UNIQUE KEY `myuser_id` (`myuser_id`,`group_id`),
   KEY `app_myuser_groups_f1d9e869` (`myuser_id`),
   KEY `app_myuser_groups_5f412f9a` (`group_id`),
   CONSTRAINT `myuser_id_refs_id_08272aba` FOREIGN KEY (`myuser_id`)
 REFERENCES `app_myuser` (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8
 }}}

 In other words, 1.7 seems to silently ignore to add constraints to missing
 tables.

 See the docs as well:
 https://docs.djangoproject.com/en/1.7/topics/migrations/#unmigrated-
 dependencies

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django 

Re: [Django] #24332: Sites migration fails when DATABASES['default'] = {}

[Django]

#24332: Sites migration fails when DATABASES['default'] = {}
-+-
 Reporter:  trecouvr |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrate  | Triage Stage:  Accepted
  post_migrate   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * severity:  Normal => Release blocker


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

Re: [Django] #24315: Using UUIDField for id of custom User model prevents password reset confirm view

[Django]

#24315: Using UUIDField for id of custom User model prevents password reset 
confirm
view
-+--
 Reporter:  jamesbeith   |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.8alpha1
 Severity:  Release blocker  |   Resolution:  worksforme
 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):

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


Comment:

 I couldn't reproduce this. See previous comment for a patch which modifies
 an existing test in Django's test suite for password reset to use a
 `UUIDUser`. Please reopen if you can provide more details (ideally,
 modifying that test so that it fails).

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

[Django]

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"47b23ca2ee4d26a50895adf0fba19020b27d8d84"]:
 {{{
 #!CommitTicketReference repository=""
 revision="47b23ca2ee4d26a50895adf0fba19020b27d8d84"
 [1.8.x] Refs #14030 -- Added tests for Value aggregates

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

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

[Django]

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  aggregate, annotate  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"bd4afef98490198e325654952d38a5735ee7e358"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bd4afef98490198e325654952d38a5735ee7e358"
 Refs #14030 -- Added tests for Value aggregates
 }}}

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

Re: [Django] #23756: Fall DST change breaks timezone.py make_aware

[Django]

#23756: Fall DST change breaks timezone.py make_aware
---+
 Reporter:  mdineen|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  1.7
 Severity:  Normal |   Resolution:  invalid
 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 carljm):

 @jbg The main reason I can see not to add the `is_dst` argument is that
 (if you're using pytz, which you certainly should be if you care at all
 about correct timezone handling) `timezone.make_aware(value, tz)` is
 simply a different spelling of `tz.localize(value)`, and the latter is
 actually shorter, and already has the `is_dst` argument. So if you are
 using `pytz`, there's really no reason not to just use `tz.localize()`
 instead of `timezone.make_aware()`. The only real purpose of
 `timezone.make_aware()` is to offer semi-correct handling for the no-pytz
 case, and in that case I don't think there's anything sane we could do
 with the `is_dst` argument anyway.

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

Re: [Django] #23756: Fall DST change breaks timezone.py make_aware

[Django]

#23756: Fall DST change breaks timezone.py make_aware
---+
 Reporter:  mdineen|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  1.7
 Severity:  Normal |   Resolution:  invalid
 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 jbg):

 I understand the rationale for closing this but wonder whether make_aware
 could offer an is_dst option to be passed through, allowing the caller of
 make_aware to resolve the ambiguity if possible?

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

Re: [Django] #24319: UUIDField do not properly clean (validate) value in get_db_prep_value

[Django]

#24319: UUIDField do not properly clean (validate) value in get_db_prep_value
-+-
 Reporter:  davidfischer-ch  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  clean,uuid   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"1784c326b1040bc1957a6f9664fdd2a8647bde50"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1784c326b1040bc1957a6f9664fdd2a8647bde50"
 [1.8.x] Fixed #24319 -- Added validation for UUID model field

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

Re: [Django] #24319: UUIDField do not properly clean (validate) value in get_db_prep_value

[Django]

#24319: UUIDField do not properly clean (validate) value in get_db_prep_value
-+-
 Reporter:  davidfischer-ch  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  clean,uuid   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josh Smeaton ):

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


Comment:

 In [changeset:"de0241eb985c6dec978beda119fee353ef3e9604"]:
 {{{
 #!CommitTicketReference repository=""
 revision="de0241eb985c6dec978beda119fee353ef3e9604"
 Fixed #24319 -- Added validation for UUID model field
 }}}

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

Re: [Django] #24332: Sites migration fails when DATABASES['default'] = {}

[Django]

#24332: Sites migration fails when DATABASES['default'] = {}
-+-
 Reporter:  trecouvr |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrate  | Triage Stage:  Accepted
  post_migrate   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_tests:  1 => 0


Comment:

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

Re: [Django] #24334: auth admin password reset doesn't work with non-digit custom user PK

[Django]

#24334: auth admin password reset doesn't work with non-digit custom user PK
--+-
 Reporter:  timgraham |Owner:  timgraham
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.8alpha1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


Comment:

 Test is working now (added `connection.constraint_checks_disabled` to fix
 MySQL).

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

Re: [Django] #24307: Oracle Syncdb breaks trying to set NULL to column that already is NULL

[Django]

#24307: Oracle Syncdb breaks trying to set NULL to column that already is NULL
-+-
 Reporter:  JorisBenschop|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle 1.8-beta  | 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):

 * keywords:   => oracle 1.8-beta
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Not sure offhand, what version of Oracle (in case it matters)? I'll try to
 make sure someone investigates this issue before 1.8 beta.

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

Re: [Django] #24320: Unable to serialize UUIDField when running dumpdata with JSON format

[Django]

#24320: Unable to serialize UUIDField when running dumpdata with JSON format
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core |  Version:  1.8alpha1
  (Serialization)|
 Severity:  Release blocker  |   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):

 Thanks. Problem seems to be having a FK to an object with a UUID pk.
 Attaching a failing test for Django's test suite.

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

Re: [Django] #24290: postgres_tests fail ungracefully if psycopg2 isn't installed

[Django]

#24290: postgres_tests fail ungracefully if psycopg2 isn't installed
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  joelburton
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.8  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Created #24335 for the `DateRange` import failure.

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

[Django] #24335: DateRange and friends require psycopg2 >= 2.5

[Django]

#24335: DateRange and friends require psycopg2 >= 2.5
-+-
   Reporter:  claudep|  Owner:
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  1.8alpha1
  contrib.postgres   |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently, if your psycopg2 version is lower than 2.5, you cannot import
 any of contrib.postgres fields or forms, as ranges.py is unconditionally
 imported in their `__init__`.

 On one side, this should be documented, and on the other side we should
 still allow other fields/forms (array/hstore) to be imported (maybe raise
 a RuntimeWarning for the ranges import failure?).

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

Re: [Django] #24320: Unable to serialize UUIDField when running dumpdata with JSON format

[Django]

#24320: Unable to serialize UUIDField when running dumpdata with JSON format
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core |  Version:  1.8alpha1
  (Serialization)|
 Severity:  Release blocker  |   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 jamesbeith):

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


Comment:

 I have created an example project which reproduces the 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/068.d2d5890e2271744f11c3cb330adfb8f8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24282: Cannot Modify Foreign Keys Within Data Migrations

[Django]

#24282: Cannot Modify Foreign Keys Within Data Migrations
-+-
 Reporter:  jeffasinger  |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8alpha1
 Severity:  Release blocker  |   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 coldmind):

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


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

Re: [Django] #24333: admin history view can fail with non-integer slug

[Django]

#24333: admin history view can fail with non-integer slug
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"03f4e2d90997aec4c8f57c5c9b7925d70194327e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="03f4e2d90997aec4c8f57c5c9b7925d70194327e"
 [1.8.x] Fixed #24333 -- Fixed admin history view crash with non-integer
 slug.

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

Re: [Django] #24333: admin history view can fail with non-integer slug

[Django]

#24333: admin history view can fail with non-integer slug
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"d64baaef3b95abe9ae5d07317c9bf4df02cb8592"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d64baaef3b95abe9ae5d07317c9bf4df02cb8592"
 Fixed #24333 -- Fixed admin history view crash with non-integer slug.
 }}}

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

Re: [Django] #24333: admin history view can fail with non-integer slug

[Django]

#24333: admin history view can fail with non-integer slug
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24332: Sites migration fails when DATABASES['default'] = {}

[Django]

#24332: Sites migration fails when DATABASES['default'] = {}
-+-
 Reporter:  trecouvr |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrate  | Triage Stage:  Accepted
  post_migrate   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Old description:

> {{{
>
> }}}
> On Django 1.7.4 the management command `migrate --database=xxx` fails
> when `DATABASES['default'] = {}` with
> `django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
> improperly configured. Please supply the ENGINE value. Check settings
> documentation for more details.`.
> On Django 1.7.3 it works fine.
> More details can be found on https://code.djangoproject.com/ticket/24298.
>
> To reproduce the problem:
>
> 1. Create a new project
> 2. Edit the settings.py this way:
>

> {{{
> DATABASES = {
> 'default': {},
> 'mysite': {
> 'ENGINE': 'django.db.backends.sqlite3',
> 'NAME': os.path.join(BASE_DIR, 'db_mysite.sqlite3'),
> }
> }
> }}}
>
> 3. Run python manage.py migrate --database=mysite
>
> Problem:
> It seems Django tries to access the default connection.
>

> I am attaching an output log of the command.
> Here is a sample project to reproduce the behaviour:
> ​https://github.com/trecouvr/test_dj_migrate_174.

New description:

 On Django 1.7.4 the management command `migrate --database=xxx` fails when
 `DATABASES['default'] = {}` with
 `django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
 improperly configured. Please supply the ENGINE value. Check settings
 documentation for more details.`.
 On Django 1.7.3 it works fine.
 More details can be found on https://code.djangoproject.com/ticket/24298.

 To reproduce the problem:

 1. Create a new project
 2. Edit the settings.py this way:


 {{{
 DATABASES = {
 'default': {},
 'mysite': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': os.path.join(BASE_DIR, 'db_mysite.sqlite3'),
 }
 }
 }}}

 3. Run python manage.py migrate --database=mysite

 Problem:
 It seems Django tries to access the default connection.


 I am attaching an output log of the command.
 Here is a sample project to reproduce the behaviour:
 ​https://github.com/trecouvr/test_dj_migrate_174.

--

Comment:

 [https://github.com/django/django/pull/4120 PR] (not sure about tests at
 the moment)

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

Re: [Django] #24334: auth admin password reset doesn't work with non-digit custom user PK

[Django]

#24334: auth admin password reset doesn't work with non-digit custom user PK
--+-
 Reporter:  timgraham |Owner:  timgraham
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.8alpha1
 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 timgraham):

 * owner:  nobody => timgraham
 * status:  new => assigned
 * has_patch:  0 => 1
 * needs_better_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/4118 PR] (with one issue to be
 fixed)

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

[Django] #24334: auth admin password reset doesn't work with non-digit custom user PK

[Django]

#24334: auth admin password reset doesn't work with non-digit custom user PK
+---
   Reporter:  timgraham |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  contrib.auth  |Version:  1.8alpha1
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  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/052.37ade7405315825f91d29cfa87688680%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24333: admin history view can fail with non-integer slug

[Django]

#24333: admin history view can fail with non-integer slug
---+-
 Reporter:  timgraham  |Owner:  timgraham
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/4119 PR]

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

[Django] #24333: admin history view can fail with non-integer slug

[Django]

#24333: admin history view can fail with non-integer slug
-+---
   Reporter:  timgraham  |  Owner:  timgraham
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  1.7
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
 A URL like `/admin/app/model/bad/history/` will raise `ValueError` if
 model's pk is an integer.

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

Re: [Django] #24289: Is usage of many_to_one and one_to_many terms confusing for relation flags?

[Django]

#24289: Is usage of many_to_one and one_to_many terms confusing for relation 
flags?
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   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 carljm):

 * cc: pirosb3 (added)


Comment:

 Also adding PirosB3 to cc in case he has additional thoughts on this,
 since he wrote the code.

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

Re: [Django] #24215: Refactor of lazy model operations

[Django]

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"9239f1dda7b94f53d21efb8b5e4d056e24f4e906"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9239f1dda7b94f53d21efb8b5e4d056e24f4e906"
 Refs #24215 -- Prevented pending lookup pollution by abstract models.
 }}}

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

Re: [Django] #21175: abstract base model classes never fire class_prepared signal

[Django]

#21175: abstract base model classes never fire class_prepared signal
-+-
 Reporter:  carljm   |Owner:  cbabs
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 carljm):

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


Comment:

 I am closing this; in light of #24313 and discussion on #24215, I no
 longer think it makes sense for abstract models to fire `class_prepared`.
 (In fact I'm hopeful that we can get rid of `class_prepared` altogether,
 making it moot.)

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

Re: [Django] #24330: Test suites for modular components - storage class, cache backends.

[Django]

#24330: Test suites for modular components - storage class, cache backends.
---+--
 Reporter:  georgewhewell  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  1.7
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  testing, storage   | 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
 * needs_docs:   => 0
 * resolution:   => needsinfo
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Have you tried running Django's test suite and overriding
 `DEFAULT_FILE_STORAGE` with the storage you want to test?  I guess the end
 result might look similar to how we have features flags on the database
 backend API so that we can skip tests that don't implement certain things.
 I'm going to close this ticket as it seems too broad and not actionable
 without further research. If you are interested in tackling it, I'd
 suggest to write to the DevelopersMailingList to get feedback on your
 proposal.

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

Re: [Django] #24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage

[Django]

#24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage
--+--
 Reporter:  matt-leach|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.messages  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 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:   => wontfix


Comment:

 Sure, I guess it might be nice if the test actually verified that value
 since even `success_url = 'foo'` doesn't result in a test failure. Feel
 free to submit a PR.

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

Re: [Django] #24303: Not all models available in custom data migration

[Django]

#24303: Not all models available in custom data migration
-+--
 Reporter:  grandfatha   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  worksforme
 Keywords:  data migrations  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by grandfatha):

 Oh god that was a bad idea. If anyone ever reads this: Use a real
 migration instead of "__first__" if your data migration requires fields
 that will be added after "__first__". It might sound nice to not depend on
 a specific version, but it can cause failure.

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

Re: [Django] #24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage

[Django]

#24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage
--+--
 Reporter:  matt-leach|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.messages  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by matt-leach):

 Have just noticed that in tests/messages_tests/urls.py
 `ContactFormViewWithMsg` should use reverse_lazy (as below) rather than
 passing in the view object to success url (`success_url = show`). Is that
 worth fixing?

 {{{
 class ContactFormViewWithMsg(SuccessMessageMixin, FormView):
 form_class = ContactForm
 success_url = reverse_lazy('show_message')
 success_message = "%(name)s was created successfully"
 }}}

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

Re: [Django] #24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage

[Django]

#24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage
--+--
 Reporter:  matt-leach|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.messages  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by matt-leach):

 Fair enough. I didn't have a use case except that it means the tests will
 fail if you change the `MESSAGE_STORAGE` variable.

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

Re: [Django] #24332: Sites migration fails when DATABASES['default'] = {}

[Django]

#24332: Sites migration fails when DATABASES['default'] = {}
-+-
 Reporter:  trecouvr |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrate  | Triage Stage:  Accepted
  post_migrate   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  nobody => timgraham
 * status:  new => assigned
 * stage:  Unreviewed => Accepted


Comment:

 Oh, I see, will look at 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/066.ce3b4948432776630a45debfc9ed3779%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24332: Sites migration fails when DATABASES['default'] = {}

[Django]

#24332: Sites migration fails when DATABASES['default'] = {}
-+-
 Reporter:  trecouvr |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrate  | Triage Stage:
  post_migrate   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by trecouvr):

 I am not sure if I misunderstood him or not, but I get the error reported
 on this ticket with branch stable/1.7.x and this is not exactly the same
 as mentioned in #24298. This looks like the same as #24298 but the root
 cause is not the same (The root cause of #24298 is the post_migrate call
 related to the 'auth' application whereas here the error is related to the
 'sites' application).

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

Re: [Django] #24320: Unable to serialize UUIDField when running dumpdata with JSON format

[Django]

#24320: Unable to serialize UUIDField when running dumpdata with JSON format
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:  1.8alpha1
  (Serialization)|
 Severity:  Release blocker  |   Resolution:  needsinfo
 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):

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


Comment:

 Please reopen with more details if this is still an 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/068.590c0e809ec1504baf5d1a046a76e859%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24320: Unable to serialize UUIDField when running dumpdata with JSON format

[Django]

#24320: Unable to serialize UUIDField when running dumpdata with JSON format
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core |  Version:  1.8alpha1
  (Serialization)|
 Severity:  Release blocker  |   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 Tim Graham ):

 In [changeset:"8d1816db87e9e700d9bd5336ac25686fdf30c789"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8d1816db87e9e700d9bd5336ac25686fdf30c789"
 [1.8.x] Added a test for UUIDField serialization; refs #24320.

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

Re: [Django] #24320: Unable to serialize UUIDField when running dumpdata with JSON format

[Django]

#24320: Unable to serialize UUIDField when running dumpdata with JSON format
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core |  Version:  1.8alpha1
  (Serialization)|
 Severity:  Release blocker  |   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 Tim Graham ):

 In [changeset:"d7509c52466aeffb13ccd8a86475e74fdb0e6292"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d7509c52466aeffb13ccd8a86475e74fdb0e6292"
 Added a test for UUIDField serialization; refs #24320.
 }}}

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

Re: [Django] #24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage

[Django]

#24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage
--+--
 Reporter:  matt-leach|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.messages  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

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


Comment:

 I don't think there's a need to specify default settings in
 `override_settings()` everywhere we rely on them. Did you have some use
 case in mind?

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

Re: [Django] #24332: Sites migration fails when DATABASES['default'] = {}

[Django]

#24332: Sites migration fails when DATABASES['default'] = {}
-+-
 Reporter:  trecouvr |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrate  | Triage Stage:
  post_migrate   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Old description:

> On Django 1.7.4 the management command `migrate --database=xxx` fails
> when `DATABASES['default'] = {}` with
> `django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
> improperly configured. Please supply the ENGINE value. Check settings
> documentation for more details.`.
> On Django 1.7.3 it works fine.
> More details can be found on https://code.djangoproject.com/ticket/24298.
>
> To reproduce the problem:
>
> 1. Create a new project
> 2. Edit the settings.py this way:
>

> {{{
> DATABASES = {
> 'default': {},
> 'mysite': {
> 'ENGINE': 'django.db.backends.sqlite3',
> 'NAME': os.path.join(BASE_DIR, 'db_mysite.sqlite3'),
> }
> }
> }}}
>
> 3. Run python manage.py migrate --database=mysite
>
> Problem:
> It seems Django tries to access the default connection.
>

> I am attaching an output log of the command.
> Here is a sample project to reproduce the behaviour:
> ​https://github.com/trecouvr/test_dj_migrate_174.

New description:

 {{{

 }}}
 On Django 1.7.4 the management command `migrate --database=xxx` fails when
 `DATABASES['default'] = {}` with
 `django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
 improperly configured. Please supply the ENGINE value. Check settings
 documentation for more details.`.
 On Django 1.7.3 it works fine.
 More details can be found on https://code.djangoproject.com/ticket/24298.

 To reproduce the problem:

 1. Create a new project
 2. Edit the settings.py this way:


 {{{
 DATABASES = {
 'default': {},
 'mysite': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': os.path.join(BASE_DIR, 'db_mysite.sqlite3'),
 }
 }
 }}}

 3. Run python manage.py migrate --database=mysite

 Problem:
 It seems Django tries to access the default connection.


 I am attaching an output log of the command.
 Here is a sample project to reproduce the behaviour:
 ​https://github.com/trecouvr/test_dj_migrate_174.

--

Comment:

 This seems to be a duplicate of #24298 which was fixed (did you try this
 on the stable/1.7.x branch?). Markus asked you to open a new issue for
 `create_default_site()` not propagating the `using` parameter. Did you
 misunderstand him or am I misunderstanding you?

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

[Django] #24332: Sites migration fails when DATABASES['default'] = {}

[Django]

#24332: Sites migration fails when DATABASES['default'] = {}
+--
 Reporter:  trecouvr|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.7
 Severity:  Normal  |   Keywords:  migrate post_migrate
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 On Django 1.7.4 the management command `migrate --database=xxx` fails when
 `DATABASES['default'] = {}` with
 `django.core.exceptions.ImproperlyConfigured: settings.DATABASES is
 improperly configured. Please supply the ENGINE value. Check settings
 documentation for more details.`.
 On Django 1.7.3 it works fine.
 More details can be found on https://code.djangoproject.com/ticket/24298.

 To reproduce the problem:

 1. Create a new project
 2. Edit the settings.py this way:


 {{{
 DATABASES = {
 'default': {},
 'mysite': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': os.path.join(BASE_DIR, 'db_mysite.sqlite3'),
 }
 }
 }}}

 3. Run python manage.py migrate --database=mysite

 Problem:
 It seems Django tries to access the default connection.


 I am attaching an output log of the command.
 Here is a sample project to reproduce the behaviour:
 ​https://github.com/trecouvr/test_dj_migrate_174.

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

Re: [Django] #10944: Site app should be able to make absolute URLs.

[Django]

#10944: Site app should be able to make absolute URLs.
---+--
 Reporter:  jdunck |Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  Version:  1.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by mbertheau):

 Replying to [comment:9 SmileyChris]:
 > What's actually the good in the `{% site_url %}` tag? It seems like it
 should be able to take other sites, too (if you only have one site, why
 bother using this over the standard `request.build_absolute_uri()`?)

 I often find myself in a situation where I need an absolute URL but cannot
 use `request.build_absolute_uri()` because I don't have a request: cron
 jobs, celery tasks or api modules that I don't want to couple to the
 request. Afaics Django currently doesn't have a place to generate absolute
 URLs without a request, so everyone is hacking their own way. `Site` is a
 possible place to do it, but it'd have to learn about the scheme and port
 to be complete. `RequestSite` could take these from new settings, maybe:
 `SITE_SCHEME`, `SITE_PORT`.

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

[Django] #24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage

[Django]

#24331: SuccessMessageMixinTests fail if MESSAGE_STORAGE is not CookieStorage
--+
 Reporter:  matt-leach|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.messages  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The TestCase `messages_tests.text_mixins.SuccessMessageMixinTests`checks
 that a cookie has been created. This means it will fail if the settings
 object `MESSAGE_STORAGE` is set to
 `django.contrib.messages.storage.session.SessionStorage` or anything that
 isn't `CookieStorage`.

 Probably best to fix using an
 
`override_settings(MESSAGE_STORAGE='django.contrib.messages.storage.cookie.CookieStorage')`
 decorator.

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

[Django] #24330: Test suites for modular components - storage class, cache backends.

[Django]

#24330: Test suites for modular components - storage class, cache backends.
---+--
 Reporter:  georgewhewell  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Testing framework  |Version:  1.7
 Severity:  Normal |   Keywords:  testing, storage
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 When implementing a custom storage class, there seems to be no way to
 confirm that it is behaving as expected by django. It would be useful to
 have a test suite that only used the interface provided by the
 DEFAULT_FILE_STORAGE class and checked things like saving and reading a
 file returns the same content, seeking, .url method. As not all methods
 appear mandatory, these could be skipped for backends which don't
 implement them.

 For example, the django-storages package's documentation for FTP
 backend[1] reads:

 This implementation was done preliminary for upload files in admin to
 remote FTP location and read them back on site by HTTP. It was tested
 mostly in this configuration, so read/write using FTPStorageFile class may
 break.

 It would be nice to be able to run the same tests against this backend by
 overriding the DEFAULT_FILE_STORAGE setting to determine if it will break
 or not.

 [1] https://django-storages.readthedocs.org/en/latest/backends/ftp.html

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

Re: [Django] #24290: postgres_tests fail ungracefully if psycopg2 isn't installed

[Django]

#24290: postgres_tests fail ungracefully if psycopg2 isn't installed
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  joelburton
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  1.8  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Also encountered:
 {{{
   File "/home/claude/virtualenvs/djangogit/local/lib/python2.7/site-
 packages/django/contrib/postgres/forms/ranges.py", line 1, in 
 from psycopg2.extras import DateRange, DateTimeTZRange, NumericRange
 ImportError: cannot import name DateRange
 }}}
 {{{
 >>> psycopg2.__version__
 '2.4.5 (dt dec mx pq3 ext)'
 }}}
 It might also depend on installed PostgreSQL extensions.

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

Re: [Django] #17716: include(arg, namespace=None, app_name=None) replace app_name with namespace

[Django]

#17716: include(arg, namespace=None, app_name=None) replace app_name with 
namespace
-+-
 Reporter:  blackip@…|Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  include reverse url  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"7b5aa20a281d1df27a9d94dd591845838a3cc804"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7b5aa20a281d1df27a9d94dd591845838a3cc804"
 [1.8.x] Fixed #17716 -- Prevented include('...', app_name='...') without a
 namespace.

 Backport of 27eeb64a96ec6d3a05714ab6319b500a935706fb 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/075.3bb4cab76f610562925fbe1fa54457f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24315: Using UUIDField for id of custom User model prevents password reset confirm view

[Django]

#24315: Using UUIDField for id of custom User model prevents password reset 
confirm
view
-+-
 Reporter:  jamesbeith   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.8alpha1
 Severity:  Release blocker  |   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):

 * owner:  nobody => timgraham
 * status:  new => assigned


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

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

Re: [Django] #17716: include(arg, namespace=None, app_name=None) replace app_name with namespace

[Django]

#17716: include(arg, namespace=None, app_name=None) replace app_name with 
namespace
-+-
 Reporter:  blackip@…|Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  include reverse url  | 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"27eeb64a96ec6d3a05714ab6319b500a935706fb"]:
 {{{
 #!CommitTicketReference repository=""
 revision="27eeb64a96ec6d3a05714ab6319b500a935706fb"
 Fixed #17716 -- Prevented include('...', app_name='...') without a
 namespace.
 }}}

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

Re: [Django] #24293: contrib.sites.tests.CreateDefaultSiteTests.test_multi_db expect "other" database to exist, but doesn't create one

[Django]

#24293: contrib.sites.tests.CreateDefaultSiteTests.test_multi_db expect "other"
database to exist, but doesn't create one
---+--
 Reporter:  teferi |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.sites  |  Version:  1.7
 Severity:  Normal |   Resolution:  fixed
 Keywords:  tests  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"0c9e006d5fddfe470553d792e2ecee02f467f2a8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0c9e006d5fddfe470553d792e2ecee02f467f2a8"
 [1.7.x] Fixed #24293 -- Skipped a contrib.sites test if multiple databases
 aren't setup.
 }}}

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

Re: [Django] #24325: Cannot reference FK relation from inline ModelForm.save()

[Django]

#24325: Cannot reference FK relation from inline ModelForm.save()
--+-
 Reporter:  Starou|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.8alpha1
 Severity:  Normal|   Resolution:
 Keywords:  inline ModelForm  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by knbk):

 * type:  Uncategorized => 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.62d9e27c9d36f7225e3c564b5a7d9833%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24325: Cannot reference FK relation from inline ModelForm.save()

[Django]

#24325: Cannot reference FK relation from inline ModelForm.save()
--+-
 Reporter:  Starou|Owner:  nobody
 Type:  Uncategorized |   Status:  new
Component:  Forms |  Version:  1.8alpha1
 Severity:  Normal|   Resolution:
 Keywords:  inline ModelForm  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by knbk):

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

Re: [Django] #24161: Using UUIDField for id of custom User model prevents logging in

[Django]

#24161: Using UUIDField for id of custom User model prevents logging in
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.8alpha1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"596564e808089f1263469dbf4744dcaa05b79222"]:
 {{{
 #!CommitTicketReference repository=""
 revision="596564e808089f1263469dbf4744dcaa05b79222"
 [1.8.x] Fixed #24161 -- Stored the user primary key as a serialized value
 in the session.

 This allows using a UUIDField primary key along with the JSON session
 serializer.

 Thanks to Trac alias jamesbeith for the report and Simon Charette
 for the initial patch.

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

Re: [Django] #24161: Using UUIDField for id of custom User model prevents logging in

[Django]

#24161: Using UUIDField for id of custom User model prevents logging in
-+-
 Reporter:  jamesbeith   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.8alpha1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"0f7f5bc9e7a94ab91c2b3db29ef7cf000eff593f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0f7f5bc9e7a94ab91c2b3db29ef7cf000eff593f"
 Fixed #24161 -- Stored the user primary key as a serialized value in the
 session.

 This allows using a UUIDField primary key along with the JSON session
 serializer.

 Thanks to Trac alias jamesbeith for the report and Simon Charette
 for the initial 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/068.87f6f5f40755b7739cf652cb185db7cc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24328: The new Options._get_fields() method needs to be cleaned up

[Django]

#24328: The new Options._get_fields() method needs to be cleaned up
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-beta | 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):

 * cc: pirosb3 (added)
 * keywords:   => 1.8-beta
 * stage:  Unreviewed => Accepted


Comment:

 Didn't look through all these, but `export_ordered_set` seems to be used
 when calling the function recursively. Dan, do you have time to address
 these issues?

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

Re: [Django] #24329: Is Django 1.8a1 suppose to be on PyPi?

[Django]

#24329: Is Django 1.8a1 suppose to be on PyPi?
---+--
 Reporter:  kegan  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.8alpha1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 Yes it is. Please upgrade to a newer version of pip to prevent the
 installation of prereleases; see #21108 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/063.5b3c06d02ac83e278109efac0569f2ff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24304: Migrations are being created if you overwrite a translation

[Django]

#24304: Migrations are being created if you overwrite a translation
-+-
 Reporter:  codingjoe|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  i18n, migrations,| Triage Stage:
  makemigrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Please read our [https://docs.djangoproject.com/en/dev/internals/release-
 process/#supported-versions supported 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/067.46f3d9cffdd1e97900ac0efe4df8d86e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24319: UUIDField do not properly clean (validate) value in get_db_prep_value

[Django]

#24319: UUIDField do not properly clean (validate) value in get_db_prep_value
-+-
 Reporter:  davidfischer-ch  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  clean,uuid   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

Re: [Django] #24304: Migrations are being created if you overwrite a translation

[Django]

#24304: Migrations are being created if you overwrite a translation
-+-
 Reporter:  codingjoe|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  i18n, migrations,| Triage Stage:
  makemigrations |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by codingjoe):

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


Comment:

 Thanks claudep,
 Seems to be fixed in #24073

 Just out of interest how do you decide on wether or not a bug will be
 fixed in a major or minor version?

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

Re: [Django] #24215: Refactor of lazy model operations

[Django]

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by MarkusH):

 Hey Anssi,

 as part of #24225 and #24264 I re-implemented the model reloading process
 in PR 4097. For now it recursively looks at a model's references, removes
 all of them from the app registry and adds them again. In case that might
 be worth knowing.

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

Re: [Django] #24303: Not all models available in custom data migration

[Django]

#24303: Not all models available in custom data migration
-+--
 Reporter:  grandfatha   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  worksforme
 Keywords:  data migrations  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by grandfatha):

 When trying this within my app, I got:

   File ".../site-packages/django/db/migrations/graph.py", line 46, in
 add_dependency
 "Migration %s dependencies reference nonexistent parent node %r" %
 (migration, parent)
 KeyError: u"Migration items.0006_auto_20150212_1138 dependencies reference
 nonexistent parent node (u'attributes', u'0001_initial.py')"


 I changed it to:

 {{{

 class Migration(migrations.Migration):

 dependencies = [
 ('items', '0005_probe_is_active'),
 ('attributes', '__first__'),
 ('actions', '__first__'),
 ]

 operations = [
migrations.RunPython(code=forwards)
 ]

 }}}

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

Re: [Django] #24317: Deprecate field.rel, replace it with real field instances

[Django]

#24317: Deprecate field.rel, replace it with real field instances
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 My current thoughts of how relation fields should work is:

 A relation in Django consits of:
   - The field itself
   - A descriptor to access the objects of the relation
   - The descriptor might need a custom manager
   - Possibly a remote field (the field to travel the relation in other
 direction)
   - The remote field can contain a descriptor and a manager
   - For deprecation period, field.rel is something like the remote field,
 but without
 actually being a field instance.

 The loading order is as follows:
   - The relation field is created as part of loading the class (or
 completely separately
 by migrations for example).
   - The relation field is added to the class (contribute_to_class is
 called). The field is
 added to model's _meta.
   - When both the origin and the target classes are present, the
 remote_field is created
 and the descriptors are added. The remote field is added to the target
 class' _meta (note:
 the target class' _meta wasn't touched before the remote fields
 refactor!)
   - For migrations it is possible that a model is replaced live in the
 app-cache. For example,
 assume model Author is changed, and it is thus reloaded. Model Book
 has foreign key to
 Author, so its reverse field must be recreated in the Author model,
 too. The way this is
 done is that we collect all fields that have been auto-created as
 relationships into the
 Author model, and recreate the related field once Author has been
 reloaded.

 I also thought of making field.rel actually a field subclass. But I'm not
 too enthusiastic of doing this, this ties the new implementations to the
 old Rel API. It seems better to write the new remote fields from scratch,
 and then make them as much as possible Rel like for deprecation period
 (the problem being that field.rel instances are what you get from
 _meta.get_field[s]() calls).

 Note that even if this ticket is accepted, this work is still in early
 stages, and it isn't that clear how we actually want to do this. Maybe a
 DEP is in order for this? However, it is clear to me that we want to do
 *some* cleanup. It isn't nice at all that you can get instances that
 implement different APIs from get_field() and friends.

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

Re: [Django] #24215: Refactor of lazy model operations

[Django]

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I'm working on refactoring the way relation fields are implemented in
 Django (#24317). One part of the work is to store directly the remote
 parts of fields in the remote model's _meta. This isn't that complex to do
 when first creating the models, but when doing partial re-renders for
 migrations we need some way to re-fire the equivalent of class-prepared
 signal. The ticket contains a larger explanation of what I'm planning to
 do. The last point in the plan is the troublesome case. Ideas 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/066.d58622d882b5b7dd5ae09762ea334196%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24329: Is Django 1.8a1 suppose to be on PyPi?

[Django]

#24329: Is Django 1.8a1 suppose to be on PyPi?
---+---
 Reporter:  kegan  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.8alpha1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+---
 https://pypi.python.org/pypi/Django

 If I do a "pip install -U django" ... it will upgrade to 1.8a1.

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

Re: [Django] #24303: Not all models available in custom data migration

[Django]

#24303: Not all models available in custom data migration
-+--
 Reporter:  grandfatha   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  worksforme
 Keywords:  data migrations  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by grandfatha):

 Thank you for your input!

 So I should depend on the first or latest migration of all the apps that I
 use?

 In the case as described above, would as shown below be the correct way to
 go?

 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ('items','0001_initial.py'),
 ('attributes','0001_initial.py'),
 ('actions','0001_initial.py'),
 ]

 operations = [
 migrations.RunPython(code=forwards)
 ]

 }}}

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

Re: [Django] #24215: Refactor of lazy model operations

[Django]

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by AlexHill):

 That sounds sensible. Thanks for bringing that ticket to my attention.

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

Re: [Django] #24313: Deprecate the class_prepared signal

[Django]

#24313: Deprecate the class_prepared signal
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 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 AlexHill):

 Replying to [comment:2 carljm]:
 > For reference, the only place Django internally uses `class_prepared` is
 to call `do_pending_lookups` to handle unresolved relations to the just-
 loaded model. It certainly seems that could/should be handled by the app
 registry instead...

 Hi Carl, I've opened ticket #24215 and
 [https://github.com/django/django/pull/3984/files written a patch] to do
 just this - feedback 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/067.2025c27f28c0c22375600db0850baf71%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24328: The new Options._get_fields() method needs to be cleaned up

[Django]

#24328: The new Options._get_fields() method needs to be cleaned up
-+-
   Reporter:  akaariai   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  1.8alpha1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 At least the method _get_fields() has a lot of places where the code isn't
 as clean as it should be.

 Examples from master:
   - The method has a flag export_ordered_set, but that flag is never used,
 and the method definitely doesn't export an ordered set.
   - The comment in the first try-catch states that the method must always
 return a shallow copy. However, the comment doesn't make any sense in that
 location (the code doesn't make a shallow copy in that location)
   - The method constructs an OrderedDict of field -> boolean. The boolean
 flag is always True and never used. It would be possible to use an
 ordinary list instead.
   - The comment in the beginning of "if not export_ordered_set" isn't
 accurate, it states that
{{{
 # By default, fields contains field instances as keys and all
# possible names if the field instance as values. When
# _get_fields() is called, we only want to return field
 instances,
# so we just preserve the keys.
}}}
this comment doesn't make much sense.

 Other parts of the code seem to be lot better. In addition, L592 contains
 f.rel.field.rel.is_hidden(). But f.rel.field.rel is always the same as
 f.rel. L476 states that the code calls _get_fields() with
 export_ordered_set=True, but that isn't actually happening.

 The functionality itself seems to be fine, but there is just a lot of
 left-overs from internal refactorings.

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

Re: [Django] #24327: Form labels: Append colon if label ends with dot (at least in Czech)

[Django]

#24327: Form labels: Append colon if label ends with dot (at least in Czech)
-+-
 Reporter:  vzima|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.7
  Internationalization   |
 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 claudep):

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


Comment:

 We have purposefully set the suffix list to a translatable string, so as
 it can be overridden per language. The proposed solution is probably
 right, but then translations issues are not tracked here, just update the
 string on Transifex (now is a good time to target 1.8).

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

Re: [Django] #24323: NameError: global name XXXXXAdmin is not defined when using admin register decorator with an __init__ super call

[Django]

#24323: NameError: global name XAdmin is not defined when using admin 
register
decorator with an __init__ super call
---+
 Reporter:  eskhool|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by charettes):

 * needs_docs:  0 => 1


Comment:

 Because of the way model admin registration and class decoration works I
 doubt we'll be able to fix this in an elegant way.

 I suggest we document to use `site.register` if you have to reference your
 model admin during its initialization phase or simply use
 `super().__init__` on Python 3.

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

Re: [Django] #14952: New find_commands(management_dir) to support .pyc and .pyo

[Django]

#14952: New find_commands(management_dir) to support .pyc and .pyo
---+--
 Reporter:  lgx@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Other)   |  Version:  1.2
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  find_commands  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by claudep):

 Support for management commands has been added in Django 1.8 (#8280).
 Migrations is another story (#23406).

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

Re: [Django] #24215: Refactor of lazy model operations

[Django]

#24215: Refactor of lazy model operations
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 We're talking about deprecating the `class_prepared` signal altogether
 (#24313) so this should closed in the process.

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

[Django] #24327: Form labels: Append colon if label ends with dot (at least in Czech)

[Django]

#24327: Form labels: Append colon if label ends with dot (at least in Czech)
--+
 Reporter:  vzima |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Internationalization  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I have run into a feature which prevents `label_suffix` addition to the
 label if label ends with any of `':?.!'`. The problem is that this is not
 a behaviour required at least in Czech. We use much more dots in shortcuts
 than English does and in case the label ends with such a shortcut the
 colon is required to be appended at the end.

 Example: "Ulice a č.p." (Street and number) should be "Ulice a č.p.:"

 I have discussed this on django-cs group
 https://groups.google.com/forum/#!topic/django-cs/5RG8AT2VmmA and it looks
 like a bug.

 Proposed solution: Update the translation of `':?.!'` to `':?!'` in Czech.

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

Re: [Django] #14087: django.core.management.get_commands only sees commands in the last package of a namespace package

[Django]

#14087: django.core.management.get_commands only sees commands in the last 
package
of a namespace package
--+
 Reporter:  KyleMac   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 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 drakkan):

 * cc: drakkan (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/065.90c625df250cfddcdc3d159de8d1115b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14952: New find_commands(management_dir) to support .pyc and .pyo

[Django]

#14952: New find_commands(management_dir) to support .pyc and .pyo
---+--
 Reporter:  lgx@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Other)   |  Version:  1.2
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  find_commands  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by drakkan):

 * cc: drakkan (added)


Comment:

 I would like to see included this feature too, I distribute pyo files and
 I have to leave .py for migrations and management 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/070.aad3bc11e3f176b53f7454afdf74939b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24321: `utils.http.same_origin` doesn't comply with RFC6454

[Django]

#24321: `utils.http.same_origin` doesn't comply with RFC6454
+-
 Reporter:  lukasklein  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Utilities   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-

Comment (by Claude Paroz ):

 In [changeset:"1904022f91d0e987d972359d98993422db11ab3f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1904022f91d0e987d972359d98993422db11ab3f"
 [1.8.x] Fixed #24321 -- Improved `utils.http.same_origin` compliance with
 RFC6454

 Backport of 93b3ef9b2e 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/068.72a93a82fadaa2a188a70d0841573a0f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24321: `utils.http.same_origin` doesn't comply with RFC6454

[Django]

#24321: `utils.http.same_origin` doesn't comply with RFC6454
+-
 Reporter:  lukasklein  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Utilities   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"93b3ef9b2e191101c1a49b332d042864df74a658"]:
 {{{
 #!CommitTicketReference repository=""
 revision="93b3ef9b2e191101c1a49b332d042864df74a658"
 Fixed #24321 -- Improved `utils.http.same_origin` compliance with RFC6454
 }}}

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