[Django] #30749: Admin date_hierarchy filter by month of October 2019 does not include October 31th when TZ is set to Europe/Paris (UTC+2)

2019-09-02 Thread Django
#30749: Admin date_hierarchy filter by month of October 2019 does not include
October 31th when TZ is set to Europe/Paris (UTC+2)
-+-
   Reporter:  yab|  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  2.2
  contrib.admin  |   Keywords:  timezone daylight
   Severity:  Normal |  saving time
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Steps to reproduces:
 - set USE_TZ = True and TIME_ZONE = 'Europe/Paris' in settings
 - use sqlite db
 - Create a model (Event) with a datefield
 - Create modelAdmin (EventAdmin) with date_hierarchy on that datefield
 - Create an Event on 2019-10-31 (or 2018-10-31)
 - Filter by date_hierarchy on Admin list page : it does not include that
 Event.

 Probably linked to the fact that the DST in Paris is in october (Sunday
 2019-10-27) while in others Timezones it is in November (Sunday
 2019-03-11).
 Bug maybe due to pytz ?
 Bug maybe due to the way date_hierarchy calculates date range in
 django/contrib/admin/views/main.py (lines 164-167)
 {{{
 elif month:
 # In this branch, from_date will always be the first
 of a
 # month, so advancing 32 days gives the next month.
 to_date = (from_date +
 timedelta(days=32)).replace(day=1)
 }}}

 can be uncorrectly fixed by setting:
 {{{
  to_date = (from_date + timedelta(days=32, hours = XXX)).replace(day=1)
 }}}
 where XXX = 3 (or something like that)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/046.ecf172078962c1820cd3d9651dec0ba9%40djangoproject.com.


Re: [Django] #30748: Abstract model class specifies foreign key – MySQL doesn't have it.

2019-09-02 Thread Django
#30748: Abstract model class specifies foreign key – MySQL doesn't have it.
-+-
 Reporter:  Mike Robinson|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mike Robinson):

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


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.1b2e817e30d4e7bfc4f32c575f872628%40djangoproject.com.


Re: [Django] #30748: Abstract model class specifies foreign key – MySQL doesn't have it.

2019-09-02 Thread Django
#30748: Abstract model class specifies foreign key – MySQL doesn't have it.
-+-
 Reporter:  Mike Robinson|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

Comment (by Mike Robinson):

 Reopening this, because ''something'' is broken:

 {{{
 django.db.utils.IntegrityError: (1451, 'Cannot delete or update a parent
 row: a foreign key constraint fails
 (`gga$GGA`.`forum_member_forumprofile`, CONSTRAINT
 `forum_member_forumprofile_user_id_9d6b9b6b_fk_auth_user_id` FOREIGN KEY
 (`user_id`) REFERENCES `auth_user` (`id`))')
 }}}

 If Django was supposed to do the cascading deletes by its own logic, it
 didn't.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.d852b33d272188b267cd85247608daf2%40djangoproject.com.


Re: [Django] #30748: Abstract model class specifies foreign key – MySQL doesn't have it. (was: Abstract model class specifies foreign key – MySQL doesn't have it)

2019-09-02 Thread Django
#30748: Abstract model class specifies foreign key – MySQL doesn't have it.
-+-
 Reporter:  Mike Robinson|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 felixxm):

 * status:  new => closed
 * type:  Uncategorized => Bug
 * component:  Uncategorized => Database layer (models, ORM)
 * version:  2.2 => master
 * resolution:   => invalid


Comment:

 Django doesn't use `ON DELETE CASCADE` it emulates its behavior (see
 
[https://docs.djangoproject.com/en/2.2/ref/models/fields/#django.db.models.CASCADE
 documentation]).

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.ede599ccc9f4974ee59b5f6331152b1f%40djangoproject.com.


Re: [Django] #30747: Rename internal is_safe_url() to better state effective scope.

2019-09-02 Thread Django
#30747: Rename internal is_safe_url() to better state effective scope.
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"4f61810751751b8c5070ce038ea57e949650e9e3" 4f61810]:
 {{{
 #!CommitTicketReference repository=""
 revision="4f61810751751b8c5070ce038ea57e949650e9e3"
 Fixed #30747 -- Renamed is_safe_url() to
 url_has_allowed_host_and_scheme().
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.9d40295216c45cd53afa3544469a4bda%40djangoproject.com.


Re: [Django] #30748: Abstract model class specifies foreign key – MySQL doesn't have it

2019-09-02 Thread Django
#30748: Abstract model class specifies foreign key – MySQL doesn't have it
---+--
 Reporter:  Mike Robinson  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Mike Robinson:

Old description:

> The abstract class is:
>

> {{{
> class AbstractForumProfile(models.Model):
> """
> Represents the profile associated with each forum user.
> """
> user = models.OneToOneField(
> settings.AUTH_USER_MODEL, on_delete=models.CASCADE,
> related_name='forum_profile',
> verbose_name=_('User'))
>
> # The user's avatar.
> avatar = ExtendedImageField(
> verbose_name=_('Avatar'), null=True, blank=True,
> upload_to=machina_settings.PROFILE_AVATAR_UPLOAD_TO,
> **machina_settings.DEFAULT_AVATAR_SETTINGS)
>
> # The user's signature.
> signature = MarkupTextField(
> verbose_name=_('Signature'), blank=True, null=True,
> validators=[validators.NullableMaxLengthValidator(
> machina_settings.PROFILE_SIGNATURE_MAX_LENGTH)])
>
> # The amount of posts the user has posted (only approved posts are
> considered here).
> posts_count = models.PositiveIntegerField(verbose_name=_('Total
> posts'), blank=True, default=0)
> }}}
>
> The derived class is:
> {{{
> class ForumProfile(AbstractForumProfile):
> auto_subscribe_topics = models.BooleanField(
> verbose_name='Automatically subscribe to topics you create.',
> default=False)
>
> notify_subscribed_topics = models.BooleanField(
> verbose_name='Receive an email notification on new replies to
> subscribed topics.',
> default=False)
> }}}
>
> but the resulting MySQL syntax (which does not show `ON DELETE CASCADE`
> on the `FOREIGN KEY` constraint, is:
>
> {{{
> CREATE TABLE `forum_member_forumprofile` (
>   `id` int(11) NOT NULL AUTO_INCREMENT,
>   `avatar` varchar(100) DEFAULT NULL,
>   `signature` longtext,
>   `posts_count` int(10) unsigned NOT NULL,
>   `_signature_rendered` longtext,
>   `user_id` int(11) NOT NULL,
>   `auto_subscribe_topics` tinyint(1) NOT NULL DEFAULT '0',
>   `notify_subscribed_topics` tinyint(1) NOT NULL,
>   PRIMARY KEY (`id`),
>   UNIQUE KEY `user_id` (`user_id`),
>   CONSTRAINT `forum_member_forumprofile_user_id_9d6b9b6b_fk_auth_user_id`
> FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
> ) ENGINE=InnoDB AUTO_INCREMENT=53 DEFAULT CHARSET=latin1;
> }}}

New description:

 The abstract class is:


 {{{
 class AbstractForumProfile(models.Model):
 """
 Represents the profile associated with each forum user.
 """
 user = models.OneToOneField(
 settings.AUTH_USER_MODEL, on_delete=models.CASCADE,
 related_name='forum_profile',
 verbose_name=_('User'))

 # The user's avatar.
 avatar = ExtendedImageField(
 verbose_name=_('Avatar'), null=True, blank=True,
 upload_to=machina_settings.PROFILE_AVATAR_UPLOAD_TO,
 **machina_settings.DEFAULT_AVATAR_SETTINGS)

 # The user's signature.
 signature = MarkupTextField(
 verbose_name=_('Signature'), blank=True, null=True,
 validators=[validators.NullableMaxLengthValidator(
 machina_settings.PROFILE_SIGNATURE_MAX_LENGTH)])

 # The amount of posts the user has posted (only approved posts are
 considered here).
 posts_count = models.PositiveIntegerField(verbose_name=_('Total
 posts'), blank=True, default=0)
 }}}

 The derived class is:
 {{{
 class ForumProfile(AbstractForumProfile):
 auto_subscribe_topics = models.BooleanField(
 verbose_name='Automatically subscribe to topics you create.',
 default=False)

 notify_subscribed_topics = models.BooleanField(
 verbose_name='Receive an email notification on new replies to
 subscribed topics.',
 default=False)
 }}}

 but the resulting MySQL syntax (which does not show `ON DELETE CASCADE` on
 the `FOREIGN KEY` constraint) is:

 {{{
 CREATE TABLE `forum_member_forumprofile` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `avatar` varchar(100) DEFAULT NULL,
   `signature` longtext,
   `posts_count` int(10) unsigned NOT NULL,
   `_signature_rendered` longtext,
   `user_id` int(11) NOT NULL,
   `auto_subscribe_topics` tinyint(1) NOT NULL DEFAULT '0',
   `notify_subscribed_topics` tinyint(1) NOT NULL,
   PRIMARY KEY (`id`),
   UNIQUE KEY `user_id` (`user_id`),
   CONSTRAINT 

[Django] #30748: Abstract model class specifies foreign key – MySQL doesn't have it

2019-09-02 Thread Django
#30748: Abstract model class specifies foreign key – MySQL doesn't have it
-+
   Reporter:  Mike Robinson  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 The abstract class is:


 {{{
 class AbstractForumProfile(models.Model):
 """
 Represents the profile associated with each forum user.
 """
 user = models.OneToOneField(
 settings.AUTH_USER_MODEL, on_delete=models.CASCADE,
 related_name='forum_profile',
 verbose_name=_('User'))

 # The user's avatar.
 avatar = ExtendedImageField(
 verbose_name=_('Avatar'), null=True, blank=True,
 upload_to=machina_settings.PROFILE_AVATAR_UPLOAD_TO,
 **machina_settings.DEFAULT_AVATAR_SETTINGS)

 # The user's signature.
 signature = MarkupTextField(
 verbose_name=_('Signature'), blank=True, null=True,
 validators=[validators.NullableMaxLengthValidator(
 machina_settings.PROFILE_SIGNATURE_MAX_LENGTH)])

 # The amount of posts the user has posted (only approved posts are
 considered here).
 posts_count = models.PositiveIntegerField(verbose_name=_('Total
 posts'), blank=True, default=0)
 }}}

 The derived class is:
 {{{
 class ForumProfile(AbstractForumProfile):
 auto_subscribe_topics = models.BooleanField(
 verbose_name='Automatically subscribe to topics you create.',
 default=False)

 notify_subscribed_topics = models.BooleanField(
 verbose_name='Receive an email notification on new replies to
 subscribed topics.',
 default=False)
 }}}

 but the resulting MySQL syntax (which does not show `ON DELETE CASCADE` on
 the `FOREIGN KEY` constraint, is:

 {{{
 CREATE TABLE `forum_member_forumprofile` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `avatar` varchar(100) DEFAULT NULL,
   `signature` longtext,
   `posts_count` int(10) unsigned NOT NULL,
   `_signature_rendered` longtext,
   `user_id` int(11) NOT NULL,
   `auto_subscribe_topics` tinyint(1) NOT NULL DEFAULT '0',
   `notify_subscribed_topics` tinyint(1) NOT NULL,
   PRIMARY KEY (`id`),
   UNIQUE KEY `user_id` (`user_id`),
   CONSTRAINT `forum_member_forumprofile_user_id_9d6b9b6b_fk_auth_user_id`
 FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
 ) ENGINE=InnoDB AUTO_INCREMENT=53 DEFAULT CHARSET=latin1;
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/058.3e4470847134ae2938c354dca51d1aa9%40djangoproject.com.


Re: [Django] #30745: Allow serving a default file for FileField from static URL.

2019-09-02 Thread Django
#30745: Allow serving a default file for FileField from static URL.
-+-
 Reporter:  bhch |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  2.2
  uploads/storage|
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bhch):

 The current implementation doesn't return the path relative to
 `STATIC_URL`, but to `MEDIA_URL`. Using `placeholder.png` will return
 `/media/placeholder.png` -- makes it a little difficult for apps to
 distribute a default image.

 Overriding methods is certainly an option; but this seems to be a nice
 little shortcut feature.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.cc29ffab3b4964d05bb03d06a191dd4b%40djangoproject.com.


Re: [Django] #30747: Rename internal is_safe_url() to better state effective scope.

2019-09-02 Thread Django
#30747: Rename internal is_safe_url() to better state effective scope.
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Thanks for the extra effort implementing the deprecation!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.426188ad6abde01b90a4743b62a70aed%40djangoproject.com.


Re: [Django] #30747: Rename internal is_safe_url() to better state effective scope.

2019-09-02 Thread Django
#30747: Rename internal is_safe_url() to better state effective scope.
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => Carlton Gibson
 * status:  new => assigned
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.ecc8533a9cf6d6348f555216e91078bf%40djangoproject.com.


Re: [Django] #30747: Rename internal is_safe_url() to better state effective scope.

2019-09-02 Thread Django
#30747: Rename internal is_safe_url() to better state effective scope.
-+-
 Reporter:  Carlton Gibson   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/11736 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.9ab391c1a6fed882528fdeff3ed6aded%40djangoproject.com.


[Django] #30747: Rename internal is_safe_url() to better state effective scope.

2019-09-02 Thread Django
#30747: Rename internal is_safe_url() to better state effective scope.
+
   Reporter:  Carlton Gibson|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Utilities |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The name of the private `django.utils.http.is_safe_url()` suggests it does
 more than it really does.
 Rename to `url_has_allowed_host_and_scheme()` to avoid possible confusion
 here.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/056.4a3feebb90e82613caae4671912e3f26%40djangoproject.com.


Re: [Django] #30740: collectstatic tries to connect to database

2019-09-02 Thread Django
#30740: collectstatic tries to connect to database
-+-
 Reporter:  PaszaVonPomiot   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  2.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  collectstatic| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by PaszaVonPomiot):

 The solution was to use ModelChoiceField in admin.py for ModelForm class
 that was used in AdminModel class for that particular model.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.da105bdc5334a9c1a4094395b9014160%40djangoproject.com.


Re: [Django] #28442: Error creating queryset with nested OuterRefs on a foreign key

2019-09-02 Thread Django
#28442: Error creating queryset with nested OuterRefs on a foreign key
-+-
 Reporter:  Abram Booth  |Owner:  Oliver
 |  Sauder
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"600628f8f0ab077c62223a54a6c8cde6cbbd1ed1" 600628f8]:
 {{{
 #!CommitTicketReference repository=""
 revision="600628f8f0ab077c62223a54a6c8cde6cbbd1ed1"
 Refs #28442 -- Adjusted related lookups handling of expression rhs.

 Expressions should never be prepared as other Lookup.get_prep_lookup
 implementations hint at by returning early on the presence of the
 resolve_expression attribute.

 The previous solution was only handling lookups against related fields
 pointing at AutoFields and would break for foreign keys to other fields.

 It was also causing bidirectional coupling between model fields and
 expressions which the method level import of OuterRef was a symptom of.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.104224b46c91580de8e2623094cb63d4%40djangoproject.com.


Re: [Django] #30739: OuterRef in exclude() or ~Q() uses wrong model.

2019-09-02 Thread Django
#30739: OuterRef in exclude() or ~Q() uses wrong model.
-+-
 Reporter:  Oskar Persson|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"13a8884a08342817094cc6287c7ae346100a297d" 13a8884a]:
 {{{
 #!CommitTicketReference repository=""
 revision="13a8884a08342817094cc6287c7ae346100a297d"
 Fixed #30739 -- Fixed exclusion of multi-valued lookup against outer rhs.

 OuterRef right hand sides have to be nested, just like F rhs have to,
 during the subquery pushdown split_exclude performs to ensure they are
 resolved against the outer query aliases.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.6eba63f9330a9023bafb639d968c9a86%40djangoproject.com.


Re: [Django] #29379: Add autocomplete attribute to contrib.auth fields

2019-09-02 Thread Django
#29379: Add autocomplete attribute to contrib.auth fields
-+-
 Reporter:  CHI Cheng|Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  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 Carlton Gibson ):

 In [changeset:"999891bd80b3d02dd916731a7a239e1036174885" 999891bd]:
 {{{
 #!CommitTicketReference repository=""
 revision="999891bd80b3d02dd916731a7a239e1036174885"
 Refs #29379 -- Moved autocomplete attribute to UsernameField.

 Moving the autocomplete attribute into UsernameField allows this to work
 for custom forms making use of UsernameField, removes some duplication
 in the code, and keeps consistency with the autocapitalize attribute
 that is already defined on UsernameField.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.27e9e31c3d6bc2662ae14ea13e5ae879%40djangoproject.com.


Re: [Django] #29406: Add Referrer-Policy header support

2019-09-02 Thread Django
#29406: Add Referrer-Policy header support
---+-
 Reporter:  James Bennett  |Owner:  James Bennett
 Type:  New feature|   Status:  assigned
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by Claude Paroz):

 My PR was closed in favor of the
 [https://github.com/django/django/pull/11735 one from Nick].

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.c397be9dc23dce00486f78c658eb07b9%40djangoproject.com.


Re: [Django] #30746: Add Feature-Policy header support

2019-09-02 Thread Django
#30746: Add Feature-Policy header support
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  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
-+-
Changes (by Carlton Gibson):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e3df54e6fc3a43fea97df24b86191eeb%40djangoproject.com.


Re: [Django] #30745: Allow serving a default file for FileField from static URL.

2019-09-02 Thread Django
#30745: Allow serving a default file for FileField from static URL.
-+-
 Reporter:  bhch |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  2.2
  uploads/storage|
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 I suspect the best approach here is to just use an known default relative
 to `STATIC_URL` — so instead of `/static/placeholder.png`, just
 `placeholder.png`, allowing `urljoin()` to do it's thing? (Does that not
 work for you? If not, I'd try overriding the `url` property on the field
 to handle the default case before thinking about adjusting the storage...)

 Given the sensitive nature of this, any change here will need to go via a
 full proposal to the DevelopersMailingList. I'm guessing this isn't
 something we'd be keen to change but we'd need to see exactly what's being
 proposed, and exactly how we can be sure we're not introducing a security
 regression before moving forwards. (Test cases showing that the `re` is
 correct for all manner of cases being at least a starting point there.)
 I'll mark it `needsinfo` on that basis.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.3b25e30687905d4011aadbd44297e764%40djangoproject.com.


Re: [Django] #30705: Django template permissions not working when used inside the template of an inclusion tag

2019-09-02 Thread Django
#30705: Django template permissions not working when used inside the template 
of an
inclusion tag
-+-
 Reporter:  erev0s   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  permissions, | Triage Stage:
  inclusion tag  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 The block is not rendered because `perms` is not present in the context of
 your inclusion tag, so the conditional correctly evaluates to `False`.

 Take a look at the [https://docs.djangoproject.com/en/2.2/howto/custom-
 template-tags/#inclusion-tags Inclusion tags] docs.
 You'll need to use the `takes_context` kwarg and pass a reference to
 `perms` as per the examples there.

 I recommend investigating [https://django-debug-
 toolbar.readthedocs.io/en/latest/index.html Django Debug Toolbar] to see
 exactly what templates are rendered, with exactly what contexts.

 Please see TicketClosingReasons/UseSupportChannels for appropriate support
 channels.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.185e236b23c63ca4a305356b9512866b%40djangoproject.com.


Re: [Django] #30742: ModelForm should allow passing update_fields to instance.save()

2019-09-02 Thread Django
#30742: ModelForm should allow passing update_fields to instance.save()
--+--
 Reporter:  Václav Řehák  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Forms |  Version:  2.2
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  modelform | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Carlton Gibson):

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


Comment:

 I don't think this is worth the complication. It is easily implemented
 overriding save:

 {{{
 def save(self, commit=True):
 instance = super().save(commit=False)
 if commit:
 self.instance.save(update_fields=...)
 self._save_m2m()
 return instance
 }}}

 It's a marginal use-case, not justifying adding another `Meta` option
 here.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d3eb1178757b1b3eb632522b3bffd563%40djangoproject.com.