Re: [Django] #21080: collectstatic post-processing fails for references inside comments

[Django]

#21080: collectstatic post-processing fails for references inside comments
-+
 Reporter:  shreyas@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  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 powderflask):

 Replying to [comment:10 powderflask]:
 If you need to resolve this issue in the interim, override
 ManifestStaticFilesStorage (or CachedStaticFilesStorage) and re-define the
 class patterns property:

 {{{
 from django.contrib.staticfiles import storage

 class
 PatchedManifestStaticFilesStorage(storage.ManifestStaticFilesStorage):
 """
 Override the replacement patterns to match URL-encoded quotations.
 """
 patterns = (
 ("*.css", (
 r"""(url\((?:['"]|%22|%27){0,1}\s*(.*?)(?:['"]|%22|%27){0,1}\))""",
 (r"""(@import\s*["']\s*(.*?)["'])""", """@import
 url("%s")"""),
 )),
 )
 }}}

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

Re: [Django] #29414: Inlines with no edit permission should still allow users to add new objects

[Django]

#29414: Inlines with no edit permission should still allow users to add new 
objects
---+--
 Reporter:  Paulo  |Owner:  Paulo
 Type:  Uncategorized  |   Status:  assigned
Component:  Uncategorized  |  Version:  2.0
 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 Paulo):

 PR:  https://github.com/django/django/pull/9963

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

[Django] #29414: Inlines with no edit permission should still allow users to add new objects

[Django]

#29414: Inlines with no edit permission should still allow users to add new 
objects
-+--
   Reporter:  Paulo  |  Owner:  Paulo
   Type:  Uncategorized  | Status:  assigned
  Component:  Uncategorized  |Version:  2.0
   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  |
-+--
 I think a regression was introduced in
 https://github.com/django/django/pull/6734/files#diff-
 43474443052641e2941ca9fd04138c6bR247
 where it overrides self.readonly_fields with all fields if the inline has
 no edit permission.

 This results in a strange form:

 [[Image(https://preview.ibb.co/hYd1Dy/django_inline.png)]]

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

Re: [Django] #29392: Command parsing does not handle options that conflict with `--settings`/`--pythonpath`

[Django]

#29392: Command parsing does not handle options that conflict with
`--settings`/`--pythonpath`
-+-
 Reporter:  Ryan P Kilby |Owner:  lefcourn
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by lefcourn):

 Sorry, didn't realize that there was already a commit for this issue when
 I assigned it to myself.

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

Re: [Django] #29000: RenameModel does not rename M2M column when run after AlterField/RenameField

[Django]

#29000: RenameModel does not rename M2M column when run after
AlterField/RenameField
-+
 Reporter:  David Nelson Adamec  |Owner:  Jeff
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  2.0
 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 Jeff):

 * owner:  (none) => Jeff
 * status:  new => assigned


Comment:

 Unsurprisingly, this bug also breaks backwards migrations, as the names in
 the bridge table don't match expected values.

 For the models/migrations in the tickets description, backwards migrations
 produces the expected result:
 {{{
 Traceback (most recent call last):
   File "manage.py", line 15, in 
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/core/management/__init__.py",
 line 381, in execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/core/management/__init__.py",
 line 375, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/core/management/base.py",
 line 294, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/core/management/base.py",
 line 331, in execute
 output = self.handle(*args, **options)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/core/management/base.py",
 line 83, in wrapped
 res = handle_func(*args, **kwargs)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/core/management/commands/migrate.py",
 line 203, in handle
 fake_initial=fake_initial,
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/migrations/executor.py",
 line 121, in migrate
 state = self._migrate_all_backwards(plan, full_plan, fake=fake)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/migrations/executor.py",
 line 196, in _migrate_all_backwards
 self.unapply_migration(states[migration], migration, fake=fake)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/migrations/executor.py",
 line 262, in unapply_migration
 state = migration.unapply(state, schema_editor)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/migrations/migration.py",
 line 175, in unapply
 operation.database_backwards(self.app_label, schema_editor,
 from_state, to_state)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/migrations/operations/models.py",
 line 377, in database_backwards
 self.database_forwards(app_label, schema_editor, from_state, to_state)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/migrations/operations/models.py",
 line 349, in database_forwards
 to_field,
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/backends/base/schema.py",
 line 508, in alter_field
 return self._alter_many_to_many(model, old_field, new_field, strict)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/backends/base/schema.py",
 line 863, in _alter_many_to_many
 
new_field.remote_field.through._meta.get_field(new_field.m2m_reverse_field_name()),
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/backends/base/schema.py",
 line 523, in alter_field
 old_db_params, new_db_params, strict)
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/backends/base/schema.py",
 line 605, in _alter_field
 self.execute(self._rename_field_sql(model._meta.db_table, old_field,
 new_field, new_type))
   File "/usr/local/lib/python3.6/dist-
 
packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/backends/base/schema.py",
 line 133, in execute
 cursor.execute(sql, params)
   File "/usr/local/lib/python3.6/dist-
 packages/Django-2.1.dev20180514000620-py3.6.egg/django/db/backends/utils.py",
 line 100, in execute
 return super().execute(sql, params)
   File 

Re: [Django] #29246: compilemessages management-command fails with UnicodeDecodeError

[Django]

#29246: compilemessages management-command fails with UnicodeDecodeError
-+-
 Reporter:  Tarun Gaba   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  compilemessages  | Triage Stage:
  UnicodeDecodeError |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 Per our [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy], 1.11 is only receiving
 data loss and security fixes. Can the issue be reproduce on Django's
 master branch (which supports Python 3 only).

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

Re: [Django] #29246: compilemessages management-command fails with UnicodeDecodeError

[Django]

#29246: compilemessages management-command fails with UnicodeDecodeError
-+-
 Reporter:  Tarun Gaba   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  compilemessages  | Triage Stage:
  UnicodeDecodeError |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Daniel Browne):

 * status:  closed => new
 * cc: Daniel Browne (added)
 * version:  1.9 => 1.11
 * resolution:  invalid =>


Comment:

 I can reproduce this issue on Django 1.11 which is still supported. Can
 the '.' passed to os.walk not become b'.' in order to bypass the
 unicode_literals import? I think this would solve the problem.
 
(https://github.com/django/django/blob/stable/1.11.x/django/core/management/commands/compilemessages.py#L70)

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

Re: [Django] #28462: ModelAdmin.list_editable unusably slow and memory intensive with large datasets

[Django]

#28462: ModelAdmin.list_editable unusably slow and memory intensive with large
datasets
-+-
 Reporter:  Ben Cole |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.10
 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 Carlton Gibson):

 * needs_better_patch:  1 => 0
 * 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/065.0a5163bbef4762ccd228c27fefb76562%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Sagar Chalise):

 Sorry for that, I was just replying to your queries and didn't mean to
 make any changes to ticket status.
 Replying to [comment:10 Carlton Gibson]:
 > Please stop changing the flags on the ticket.
 >
 > Accepted means "Yes, this is a reasonable ticket" — Unreviewed just
 means someone else has to make the same decisions.
 >
 > I reviewed the patch: it does need improvement tests and docs etc. When
 those points are addressed it's OK to unflag those boxes.

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

Re: [Django] #29413: `QuerySet._extract_model_params` can/should be enchanced to support lazy defaults

[Django]

#29413: `QuerySet._extract_model_params` can/should be enchanced to support lazy
defaults
-+-
 Reporter:  Viktor Danyliuk  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet | Triage Stage:
  get_or_create update_or_create |  Unreviewed
  lazy   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Viktor Danyliuk:

Old description:

> I wish to have ability to write something like this:
> {{{
> from django.utils.functional import lazy
>
> obj, created = model.objects.get_or_create(
>  key=jwt,
>  defaults=lazy(self.get_defaults_for_model, dict)(jwt)
> )
> }}}
> But at the moment `_extract_model_params` prepare defaults before it's
> realy needed.
> I think `_extract_model_params` should be separated to
> `_prepare_model_lookup` and `_prepare_model_params`.
> So it's will be possible to call `_prepare_model_params` when
> `model.DoesNotExist` or even inside `_create_object_from_params`.

New description:

 I wish to have ability to write something like this:
 {{{
 from django.utils.functional import lazy

 obj, created = model.objects.get_or_create(
  key=jwt,
  defaults=lazy(self.get_defaults_for_model, dict)(jwt)
 )
 }}}
 But at the moment `_extract_model_params` prepare defaults before it's
 realy needed.
 I think `_extract_model_params` should be separated to
 `_prepare_model_lookup` and `_prepare_model_params`.
 So it will be possible to call `_prepare_model_params` when
 `model.DoesNotExist` or even inside `_create_object_from_params`.

--

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

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Carlton Gibson):

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


Comment:

 Please stop changing the flags on the ticket.

 Accepted means "Yes, this is a reasonable ticket" — Unreviewed just means
 someone else has to make the same decisions.

 I reviewed the patch: it does need improvement tests and docs etc. When
 those points are addressed it's OK to unflag those boxes.

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

Re: [Django] #29413: `QuerySet._extract_model_params` can/should be enchanced to support lazy defaults

[Django]

#29413: `QuerySet._extract_model_params` can/should be enchanced to support lazy
defaults
-+-
 Reporter:  Viktor Danyliuk  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet | Triage Stage:
  get_or_create update_or_create |  Unreviewed
  lazy   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Viktor Danyliuk:

Old description:

> I wish to have ability to write something like this:
> {{{
> from django.utils.functional import lazy
>
> obj, created = model.objects.select_related('user').get_or_create(
>  key=jwt,
>  defaults=lazy(self.get_defaults_for_model, dict)(jwt)
> )
> }}}
> But at the moment `_extract_model_params` prepare defaults before it's
> realy needed.
> I think `_extract_model_params` should be separated to
> `_prepare_model_lookup` and `_prepare_model_params`.
> So it's will be possible to call `_prepare_model_params` when
> `model.DoesNotExist` or even inside `_create_object_from_params`.

New description:

 I wish to have ability to write something like this:
 {{{
 from django.utils.functional import lazy

 obj, created = model.objects.get_or_create(
  key=jwt,
  defaults=lazy(self.get_defaults_for_model, dict)(jwt)
 )
 }}}
 But at the moment `_extract_model_params` prepare defaults before it's
 realy needed.
 I think `_extract_model_params` should be separated to
 `_prepare_model_lookup` and `_prepare_model_params`.
 So it's will be possible to call `_prepare_model_params` when
 `model.DoesNotExist` or even inside `_create_object_from_params`.

--

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

[Django] #29413: `QuerySet._extract_model_params` can/should be enchanced to support lazy defaults

[Django]

#29413: `QuerySet._extract_model_params` can/should be enchanced to support lazy
defaults
-+-
   Reporter:  Viktor |  Owner:  nobody
  Danyliuk   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  2.0
  layer (models, ORM)|   Keywords:  QuerySet
   Severity:  Normal |  get_or_create update_or_create lazy
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I wish to have ability to write something like this:
 {{{
 from django.utils.functional import lazy

 obj, created = model.objects.select_related('user').get_or_create(
  key=jwt,
  defaults=lazy(self.get_defaults_for_model, dict)(jwt)
 )
 }}}
 But at the moment `_extract_model_params` prepare defaults before it's
 realy needed.
 I think `_extract_model_params` should be separated to
 `_prepare_model_lookup` and `_prepare_model_params`.
 So it's will be possible to call `_prepare_model_params` when
 `model.DoesNotExist` or even inside `_create_object_from_params`.

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

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

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+--
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  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 Sagar Chalise):

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


Comment:

 Yes, when I avoid `contrib.auth` I need to rewrite the part I moved to be
 used by my custom authentication middleware. I think it makes sense to
 provide the interface similar to `AbstractBaseUser` for maybe
 `AbstractAnonymousUser` just for code reusabilty. Obviously this can be
 thought of for other stuffs such as backends as well where there is no
 need of `Permission` 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 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.c67e46cb939aae6d00d7abf8d76ebdf9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted
 * needs_tests:  0 => 1
 * needs_docs:  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/070.25469cce9fa669004e37e14896524cf2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+--
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  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
---+--

Comment (by Carlton Gibson):

 Yes, I see how the patch is meant to work **but** unless/until we have
 #20313 in play custom anonymous users simply aren't supported. (In that
 case there's little motivation for this change.)

 Are you using a custom anonymous user yourself? If so, how are you
 switching it in? With a custom middleware? (If not, why do you want this
 change?)

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

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+--
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  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 Sagar Chalise):

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


Comment:

 Well, I hadn't thought of scenarios regarding swappable anonymous user,
 the simple use case I am seeing is similar to `AbstractBaseUser` that is
 recommended as base class of custom user in django documentation. The
 methods and attributes that are available in `AbstractBaseUser` are
 availabe in `AnonymousBaseUser`. This way I see users creating
 `AnonymousUser` class based on `AnonymousBaseUser`  if they need to
 implement  AnonymousUser  on their own especially in authentication
 middleware and when not using `contrib.auth`.

 Maybe something like:


 {{{
 class AnonymousUser(AnonymousBaseUser):
 pass
 }}}

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

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted
 * needs_tests:  0 => 1
 * needs_docs:  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/070.5664f28fa6ae85b163b241e4e2e6646c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+--
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  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):

 * type:  Uncategorized => New feature
 * version:  2.0 => master
 * component:  Uncategorized => contrib.auth


Comment:

 Hi Sagar. This is at least related to #20313. Q: How are you specifying
 your custom `AnonymousUser` class?

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

Re: [Django] #29128: makemigrations raises AppRegistryNotReady instead of ImproperlyConfigured in Django 2.0

[Django]

#29128: makemigrations raises AppRegistryNotReady instead of 
ImproperlyConfigured
in Django 2.0
-+-
 Reporter:  Jaye Doepke  |Owner:
 |  ChillarAnand
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:  Accepted
  makemigrations |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Evgeny Arshinov):

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

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+--
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.0
 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):

 * status:  closed => new
 * has_patch:  0 => 1
 * resolution:  needsinfo =>


Comment:

 Thanks Sagar. I'll re-open so we can have a look.

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

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

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

[Django]

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+--
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  2.0
 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 Sagar Chalise):

 Opened up a PR: https://github.com/django/django/pull/9948

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

Re: [Django] #29412: django.utils.text.slugify / SafeString

[Django]

#29412: django.utils.text.slugify / SafeString
---+
 Reporter:  Andreas Pelme  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Utilities  |  Version:  2.0
 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 Claude Paroz):

 * stage:  Unreviewed => Accepted


Comment:

 I would also question the usage of `mark_safe` in `slugify`. I think the
 only backwards incompatibility would be that the result of adding a
 `SafeString` to a `slugify()` value would not be safe. I don't think it's
 much of an issue, if it's documented in release notes.

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

Re: [Django] #28223: Form not always picklable due to template renderer

[Django]

#28223: Form not always picklable due to template renderer
--+-
 Reporter:  Claude Paroz  |Owner:  Gaurav Sehgal
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.11
 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 Torsten Bronger):

 * cc: Torsten Bronger (added)


Comment:

 To copy over important information from duplicate:

 This broke in 1.11 and had worked in 1.10 and before.

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

[Django] #29412: django.utils.text.slugify / SafeString

[Django]

#29412: django.utils.text.slugify / SafeString
-+
   Reporter:  Andreas Pelme  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Utilities  |Version:  2.0
   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  |
-+
 
https://github.com/django/django/commit/ccfd1295f986cdf628d774937d0b38a14584721f
 changed `SafeString.__str__` to return itself rather than a native string.

 This works fine in most places. However, interning (`sys.intern`) a
 `SafeString` does not work, it needs to be converted to a regular string
 first.

 I use slugify to generate file names and passing it on to pathlib.Path.
 Path interns strings and this breaks:

 {{{
 >>> from django.utils.text import slugify
 >>> import pathlib
 >>> pathlib.Path(slugify('foo'))
 Traceback (most recent call last):
   File "", line 1, in 
   File
 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/pathlib.py",
 line 999, in __new__
 self = cls._from_parts(args, init=False)
   File
 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/pathlib.py",
 line 656, in _from_parts
 drv, root, parts = self._parse_args(args)
   File
 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/pathlib.py",
 line 649, in _parse_args
 return cls._flavour.parse_parts(parts)
   File
 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/pathlib.py",
 line 69, in parse_parts
 parsed.append(sys.intern(rel))
 TypeError: can't intern SafeText
 >>> pathlib.Path(str(slugify('foo')))
 Traceback (most recent call last):
   File "", line 1, in 
   File
 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/pathlib.py",
 line 999, in __new__
 self = cls._from_parts(args, init=False)
   File
 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/pathlib.py",
 line 656, in _from_parts
 drv, root, parts = self._parse_args(args)
   File
 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/pathlib.py",
 line 649, in _parse_args
 return cls._flavour.parse_parts(parts)
   File
 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/pathlib.py",
 line 69, in parse_parts
 parsed.append(sys.intern(rel))
 TypeError: can't intern SafeText
 >>> pathlib.Path(slugify('foo') + '') # workaround
 PosixPath('foo')

 }}}

 The only way to work around this is to use some kind of string operation
 that will turn it into a native string but that feels like a workaround.

 Maybe the problem is not SafeString but rather that
 `django.utils.text.slugify` that does return a SafeString instead of a
 regular string? The builtin slugify filter could still return a safe
 string?

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

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

[Django]

#29379: Add autocomplete attribute to contrib.auth fields
--+
 Reporter:  CHI Cheng |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  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 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 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.2787a32531f43be55d01134f31e96831%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28223: Form not always picklable due to template renderer

[Django]

#28223: Form not always picklable due to template renderer
--+-
 Reporter:  Claude Paroz  |Owner:  Gaurav Sehgal
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.11
 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 Carlton Gibson):

 #29411 is a duplicate of this, with a slightly different reproduce case.

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

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

Re: [Django] #29411: Pickling of a form fails after a form was used in a template

[Django]

#29411: Pickling of a form fails after a form was used in a template
-+--
 Reporter:  Torsten Bronger  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

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


Comment:

 This looks like a duplicate of #28223. (The traceback error is the same as
 reported there.)

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

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