Re: [Django] #29928: TestCase doesn't check for foreign key constraints when using sqlite

[Django]

#29928: TestCase doesn't check for foreign key constraints when using sqlite
-+-
 Reporter:  Michel Samia |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite db foreign| Triage Stage:  Accepted
  key TestCase   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * has_patch:  0 => 1
 * version:  2.1 => 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.9a4404c71eeb685d4fdc29c7644f7189%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29928: TestCase doesn't check for foreign key constraints when using sqlite

[Django]

#29928: TestCase doesn't check for foreign key constraints when using sqlite
-+-
 Reporter:  Michel Samia |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite db foreign| Triage Stage:  Accepted
  key TestCase   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * owner:  nobody => Simon Charette
 * 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.a224eade2474f215bc31978187d684d9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30041: Can't use __init_subclass__ in the Model subclass directly (not as a mixin class)

[Django]

#30041: Can't use __init_subclass__ in the Model subclass directly (not as a 
mixin
class)
-+-
 Reporter:  Tatiana  |Owner:  nobody
  Tereshchenko   |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 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 Tatiana Tereshchenko):

 It seems that explicit {{{@classmethod}}} decorator helps, though
 [https://www.python.org/dev/peps/pep-0487/#requiring-an-explicit-
 decorator-on-init-subclass PEP says] that requiring it is among "rejected
 design options".
 See [https://www.python.org/dev/peps/pep-0487/#subclass-registration
 example of __init_subclass__ usage from PEP]

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

Re: [Django] #30041: Can't use __init_subclass__ in the Model subclass directly (not as a mixin class)

[Django]

#30041: Can't use __init_subclass__ in the Model subclass directly (not as a 
mixin
class)
-+-
 Reporter:  Tatiana  |Owner:  nobody
  Tereshchenko   |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 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 Tatiana Tereshchenko):

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

[Django] #30041: Can't use __init_subclass__ in the Model subclass directly (not as a mixin class)

[Django]

#30041: Can't use __init_subclass__ in the Model subclass directly (not as a 
mixin
class)
-+
   Reporter:  goosemania |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.1
   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  |
-+
 There is [https://code.djangoproject.com/ticket/28695 a closed Django
 ticket] which references PEP and describes the new {{{__init_subclass__}}}
 in Python 3.6, it solves the case when {{{__init_subclass__}}} is used in
 a mixin class.

 Unfortunately, a direct usage of __init_subclass__ in a subclass of Django
 Model class results in TypeError:

 {{{
 $ python manage.py shell
 Traceback (most recent call last):
   File "manage.py", line 15, in 
 execute_from_command_line(sys.argv)
   File "/home/tt/django_reproducer/lib64/python3.6/site-
 packages/django/core/management/__init__.py", line 381, in
 execute_from_command_line
 utility.execute()
   File "/home/tt/django_reproducer/lib64/python3.6/site-
 packages/django/core/management/__init__.py", line 357, in execute
 django.setup()
   File "/home/tt/django_reproducer/lib64/python3.6/site-
 packages/django/__init__.py", line 24, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/home/tt/django_reproducer/lib64/python3.6/site-
 packages/django/apps/registry.py", line 112, in populate
 app_config.import_models()
   File "/home/tt/django_reproducer/lib64/python3.6/site-
 packages/django/apps/config.py", line 198, in import_models
 self.models_module = import_module(models_module_name)
   File "/usr/lib64/python3.6/importlib/__init__.py", line 126, in
 import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 994, in _gcd_import
   File "", line 971, in _find_and_load
   File "", line 955, in
 _find_and_load_unlocked
   File "", line 665, in _load_unlocked
   File "", line 678, in exec_module
   File "", line 219, in
 _call_with_frames_removed
   File "/home/tt/mysite/polls/models.py", line 25, in 
 class MyPluginModel(MyMasterModel):
   File "/home/tt/django_reproducer/lib64/python3.6/site-
 packages/django/db/models/base.py", line 78, in __new__
 new_class = super_new(cls, name, bases, new_attrs, **kwargs)
 TypeError: __init_subclass__() missing 1 required positional argument:
 'cls'
 }}}


 To reproduce, just use the code below in models.py:
 (FWIW, I created a django project and then polls app using
 [https://docs.djangoproject.com/en/2.1/intro/tutorial01/ the tutorial] and
 then added the code to models.py)

 {{{
 from django.db import models


 # It works as a mixin class.
 # Expected/actual result: MyModel.some_attr == 'added_by
 __init_subclass__'

 class MyMixin:
 def __init_subclass__(cls, **kwargs):
  cls.some_attr = 'added_by __init_subclass__'
  super().__init_subclass__(**kwargs)

 class MyModel(models.Model, MyMixin):
 pass


 # It doesn't work directly in the subclass of the Model class
 # Expected result: MyPluginModel.some_attr == 'added_by __init_subclass__'
 # Actual result: TypeError: __init_subclass__() missing 1 required
 positional argument: 'cls'

 class MyMasterModel(models.Model):  # remove inheritance from models.Model
 and it will work.
 def __init_subclass__(cls, **kwargs):
  cls.some_attr = 'added_by __init_subclass__'
  super().__init_subclass__(**kwargs)

 class MyPluginModel(MyMasterModel):
 pass

 }}}

 OS: Fedora 28
 Django: 2.1.4
 Python: 3.6.6

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

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

[Django] #30040: Documentation on permissions on templates is wrong

[Django]

#30040: Documentation on permissions on templates is wrong
-+-
   Reporter:  Sakerdot   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  2.1
  Documentation  |   Keywords:  template
   Severity:  Normal |  permissions documentation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Following
 https://docs.djangoproject.com/el/1.11/topics/auth/default/#permissions,
 it's suggested that permissions should be checked on templates like this:
 {% if perms.foo.can_vote %}

 However, while running an application on production (DEBUG = False on
 settings.py), it seems like the proper way to do this is {% if
 perms.foo.vote %}, without the can_ prefix, because the perms dictionary
 doesn't have any item with can_ and it fails otherwise.

 I think I tested this on a local environment and it worked fine with the
 can_ prefix, so not sure what the deal is 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 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.cc7d64c037ccdf09d792fe3e44f05c99%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30017: Django should assume port 443 for https in django.utils.http.is_same_domain()

[Django]

#30017: Django should assume port 443 for https in
django.utils.http.is_same_domain()
---+--
 Reporter:  Ruslan Dautkhanov  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  2.1
 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 Ruslan Dautkhanov):

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


Comment:

 As I mentioned on SO, we use Django as part of Cloudera Hue product
 https://github.com/cloudera/hue
 and there is no way to inject Django configs like `ALLOWED_HOSTS` and/or
 `CSRF_TRUSTED_ORIGINS` there.
 Anyway, this would be a workaround for this problem, not a solution.

 > infer the 443 but we're making assumptions in doing so

 Port 443 is not an assumption, but part of Internet Standard RFC-2818
 https://tools.ietf.org/html/rfc2818

 > the default port is 443

 All browsers for example, when you type in https://abc.com "assume" same
 thing unless port is given,
 and they "assume" port 80 when you specify `http://` - because it's part
 of Internet Standard.

 > Neither the Host nor the `X-Forwarded-Host` include the scheme right?
 > As such it's just not right to say that `web.site.com` and
 `web.site.com:443` are the same.

 Not quite right. Django has `X-Forwarded-Proto` header and it knows that
 it's `https` and not `http`.

 That's my last attempt to reopen this ticket. Thanks for the feedback, but
 I believe this
 is a real problem in Django.

 Moreover, not sure why Django is making a big deal from `Referer` check?
 It's not a real security as `Referer` header can be easily spoofed
 https://security.stackexchange.com/questions/66165/does-referrer-header-
 checking-offer-any-real-world-security-improvement
 I wish there would be a way to disable referer check altogether.

 Thanks again.

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

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

Re: [Django] #30037: RemoteUserBackend should pass request into configure_user()

[Django]

#30037: RemoteUserBackend should pass request into configure_user()
-+-
 Reporter:  Joshua Cannon|Owner:  Joshua
 |  Cannon
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  RemoteUserBackend| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Greg W):

 Thanks for the explanation Simon!

 Joshua - sure thing, have at 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/068.e1e54459056b9fa6c82b4147268ff6d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30037: RemoteUserBackend should pass request into configure_user()

[Django]

#30037: RemoteUserBackend should pass request into configure_user()
-+-
 Reporter:  Joshua Cannon|Owner:  Joshua
 |  Cannon
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  RemoteUserBackend| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Joshua Cannon):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10751 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.490aadf6791f37851d28cf00868488a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30037: RemoteUserBackend should pass request into configure_user()

[Django]

#30037: RemoteUserBackend should pass request into configure_user()
-+-
 Reporter:  Joshua Cannon|Owner:  Joshua
 |  Cannon
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  RemoteUserBackend| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Joshua Cannon):

 * owner:  nobody => Joshua Cannon
 * 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.1db9e5f0a6812406e9dafad36da14621%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30025: dismiseAddRelatedObjectPopup() not executing change event for select element

[Django]

#30025: dismiseAddRelatedObjectPopup() not executing change event for select
element
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 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 Carlton Gibson):

 Hmmm. 

 It’s not so much that we can’t necessarily do something about it, but that
 it’s not clear yet what the issue is.

 Glad you resolved your issue.

 Lets leave this as `needsinfo` for now. If someone stubbles across the
 same, maybe they can add more.

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

Re: [Django] #30037: RemoteUserBackend should pass request into configure_user()

[Django]

#30037: RemoteUserBackend should pass request into configure_user()
---+
 Reporter:  Joshua Cannon  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  RemoteUserBackend  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Joshua Cannon):

 Actually, if you don't mind, I'd love to take a stab at it. It seems easy
 enough as a first PR, and it's something I'm needing anyways :)

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

Re: [Django] #30037: RemoteUserBackend should pass request into configure_user()

[Django]

#30037: RemoteUserBackend should pass request into configure_user()
---+
 Reporter:  Joshua Cannon  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  RemoteUserBackend  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Simon Charette):

 Hello Greg!

 The idea is to follow the usual approach used when a function signature is
 changed in a backward incompatible way. That is:

 1. Before calling the function inspect it to determine whether or not it
 uses the new or old signature. This can be done using
 `inspect.getcallargs(self.configure_user, request, user)` in this case.
 2. If a `TypeError` is raised that means the function still uses the old
 signature. That means a `RemovedInDjango31Warning` warning should be
 emitted and the function should be called with the old signature, that is
 without passing `request`.
 3. In no exceptions are raised that means the function was either not
 overridden or switched to the new signature so it can be directly called
 with the new request argument.

 Have a look at 4b9330ccc04575f9e5126529ec355a450d12e77c as an example.

 This will also require documentation updates and tests as demonstrated in
 the above example as well.

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

Re: [Django] #30039: Inconsistency error after unapplying squash migration.

[Django]

#30039: Inconsistency error after unapplying squash migration.
-+-
 Reporter:  Shehzad-Ahmed|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Squash migration,| Triage Stage:
  replaces, rolled back(UN-applied)  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Or at least tests to demonstrate 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/071.41cabea9447ce1648d368052ce1083f0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30039: Inconsistency error after unapplying squash migration.

[Django]

#30039: Inconsistency error after unapplying squash migration.
-+-
 Reporter:  Shehzad-Ahmed|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Squash migration,| Triage Stage:
  replaces, rolled back(UN-applied)  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * needs_tests:  0 => 1


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

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

Re: [Django] #30025: dismiseAddRelatedObjectPopup() not executing change event for select element

[Django]

#30025: dismiseAddRelatedObjectPopup() not executing change event for select
element
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 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 Alexander Todorov):

 Hi Carlton,
 in my particular case we have a styles select widget (bootstrap select)
 which will receive the newly added records and it had a change event
 defined like so:

 {{{
 $(select).change(function() { ... })
 }}}

 this was not triggered. However we changed it to:

 {{{
 document.getElemebtById(select).onchange = function() {  }
 }}}

 and the later handler gets triggered after the popup closes. I'm not quite
 certain what is the difference between the jQuery change handler and the
 DOM onchange one.

 If you think there's nothing Django can do about this you can close this
 ticket.

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

Re: [Django] #30025: dismiseAddRelatedObjectPopup() not executing change event for select element

[Django]

#30025: dismiseAddRelatedObjectPopup() not executing change event for select
element
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 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


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

Re: [Django] #30025: dismiseAddRelatedObjectPopup() not executing change event for select element

[Django]

#30025: dismiseAddRelatedObjectPopup() not executing change event for select
element
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.1
 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 Carlton Gibson):

 Hi Alexander.

 This all seems to work as expected in the minimal case:
 https://jsfiddle.net/fnv5Lcom/3/

 Adding the `Option` **doesn't** fire the `change` handler, as expected, so
 we call `trigger()` to do so.

 Are you able to examine what's going on in the debugger, to ensure you're
 on the right branch, and that `elem` points to the element you're
 expecting and so on?

 If you could upload a minimal project (starting from `startproject`) that
 showed the problem that would help.

 Thanks!

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

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

Re: [Django] #30017: Django should assume port 443 for https in django.utils.http.is_same_domain()

[Django]

#30017: Django should assume port 443 for https in
django.utils.http.is_same_domain()
---+--
 Reporter:  Ruslan Dautkhanov  |Owner:  (none)
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  2.1
 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 Carlton Gibson):

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


Comment:

 Neither the `Host` nor the `X-Forwarded-Host` include the scheme right? As
 such it's just not right to say that `web.site.com` and `web.site.com:443`
 are the same. The latter includes more information. (Yes, if we also
 lookup the scheme we **might** infer the `443` but we're making
 assumptions in doing so.)

 The suggested fix on Stack Overflow seems right to me. (If you must send
 the port, beyond correcting the Nginx config, you can already adjust
 `ALLOWED_HOSTS` and/or `CSRF_TRUSTED_ORIGINS` 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 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.d2502437644081c75df986625f31d018%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

[Django]

#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 No problem. Thank you for your report, and for the effort of making sure I
 followed properly. 

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

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

Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

[Django]

#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
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:

 See TicketClosingReasons/UseSupportChannels

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

Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

[Django]

#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by ksl):

 View-only user is actually the only one working as expected. Once you
 empower a user to change objects of the model, the `has_change_permission`
 logic is somewhat bypassed (or at least does not allow a per-object
 logic).

 Thank you, for taking precious time to answer.

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

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

Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

[Django]

#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  changelist | 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):

 * resolution:  worksforme => duplicate


Comment:

 Hi `ksl` — Thanks for the follow-up.

 Looks like Simon's right about it being a Duplicate of #15759. With the
 superuser all rows are shown as editable.

 The view-only user behaviour looks correct though: No rows are shown as
 editable if the user can only `view` the admin.

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

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

Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

[Django]

#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by ksl):

 Replying to [comment:5 Simon Charette]:
 > That looks like a duplicate of #15759 to me.

 Might be a duplicate indeed, except I'm not sure I understand the ''"if an
 auth backend supports per-object permissions."'' correctly.
 In our case, it's a matter of "if an object's `has_permission` returns
 `False`".

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

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

Re: [Django] #30034: Shows wrong user on list_display in LogEntryAdmin

[Django]

#30034: Shows wrong user on list_display in LogEntryAdmin
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  logentry,| Triage Stage:
  logentryadmin, list_display,   |  Unreviewed
  wrong user |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Muslu Y.):

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


Comment:

 Hi Carlton;

 Thank you for taking the time to this problem.

 I want to say that, LogEntry is using settings.AUTH_USER_MODEL for user
 but if we want to use auth_db for route (AuthRoute) then showing wrong
 user, because user_id is not same like you say.

 May be this is not bug but this is a problem. I created and tested a blank
 project as usual and worked correctly.

 How can I provide you with more information to solve the problem?

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

Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

[Django]

#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by ksl):

 * Attachment "django_test.sql" added.

 Test project postreSQL database dump

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

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

Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

[Django]

#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by ksl):

 Replying to [comment:4 Carlton Gibson]:
 > Happy to look at a project if you can provide one but just glancing at
 the code, it looks like a programming error: you’re going to need to look
 at the `request.user` to see what you should return. Otherwise you’ve
 overridden the default implementation, which protects against this sort of
 thing, and created the issue.
 >
 > You should probably be calling `super()` before your own logic, and only
 continuing if that returns `True`.

 Please find enclosed a test project reflecting our situation. In this
 project, the Question object with ID 1 should be the only one editable.
 As you understand, our logic here is not based on per-user permission
 (hence we do not use `request.user` nor do we call `super()`) but on
 **per-object** permission.

 Test project credentials:

 * User `admin` with password `adminadmin`
 * User `notadmin` with password `adminadmin`

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

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

Re: [Django] #30028: Uneditable object still editable through change_list if list_editable not empty

[Django]

#30028: Uneditable object still editable through change_list if list_editable 
not
empty
---+--
 Reporter:  ksl|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  2.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  changelist | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by ksl):

 * Attachment "django_test.tar.gz" added.

 Test project

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

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

Re: [Django] #30039: Inconsistency error after unapplying squash migration.

[Django]

#30039: Inconsistency error after unapplying squash migration.
-+-
 Reporter:  Shehzad-Ahmed|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Squash migration,| Triage Stage:
  replaces, rolled back(UN-applied)  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi. Thanks for the report. Are you able to put together a small sample
 project demonstrating 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/071.b9b701e82c2124e5e25495121ce13aea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30020: Support reading null values for numeric fields on Shapefile import via LayerMapping

[Django]

#30020: Support reading null values for numeric fields on Shapefile import via
LayerMapping
-+-
 Reporter:  Kathryn Killebrew|Owner:  Kathryn
 |  Killebrew
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  GIS, GEOS,   | Triage Stage:  Accepted
  LayerMapping   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

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