date:20170316

Re: [Django] #27675: Django postgres JSONField encoding

2017-03-16 Thread Django

Comment (by grapemix):

After debugging like crazy for a few days, we got some good news.

Short story:
Django's JSONField cannot be mixed with django-jsonfield's JSONField to
use. See: [https://bitbucket.org/schinckel/django-jsonfield/issues/57
/cannot-use-in-the-same-project-as-djangos], not even just in migration
files. After removing all migrations file and run the make migrations cmd,
everything is working.

Long story:
We had tried running Django's std postgres testcase and our testcase
seperately and mix and matched to try to reproduce the problem. Since we
used django-jsonfield's JSONField before and we would like to switch to
Django's JSONField at once, we only keep django-jsonfield's JSONField at
migrations file to 'transit'. That's why the test result is so in-
consistence. After removing all migrations file and run the make
migrations cmd, everything is working.

Since we only tested on our dev environment, we are not sure the
transition in the prod. If we have not screamed in the following days,
that means the transition in the prod is good.
Thanks everyone for your time.

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

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships"

2017-03-16 Thread Django

#27936: Add some clarifications to "Spanning multi-valued relationships"
--+
 Reporter:  Thomas Güttler|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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 Thomas Güttler):

 Yes, now I see. The real problem is that diagrams are hard to maintain. If
 maintaining them would be easier, then there would be more.

 There are several extensions for sphinx which could be used (I needed to
 remove a link to the sphinx plugin overview page, otherwise trac thinks my
 post is spam)

 But this gets off topic for this particular issue.

 Tim, what do you think?

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

[Django] #27945: RegexValidator uses search instead of match

2017-03-16 Thread Django

#27945: RegexValidator uses search instead of match
-+
   Reporter:  Shubham Jain   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.10
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 The documentation says, RegexValidator matches the regex against the
 value, and hence ideally it must use regex.match but instead uses
 regex.search.

 This looks like a 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/058.34a90145a12c9c8f2664b3ed09e40f91%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27945: RegexValidator uses search instead of match

2017-03-16 Thread Django

#27945: RegexValidator uses search instead of match
--+--
 Reporter:  Shubham Jain  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Shubham Jain):

 * type:  Uncategorized => Bug
 * has_patch:  0 => 1
 * component:  Uncategorized => Core (Other)
 * easy:  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/073.cca919a2ae48f85e98958b52ed8490f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27935: BrinIndex.suffix for postgres longer 3 char

2017-03-16 Thread Django

#27935: BrinIndex.suffix for postgres longer 3 char
--+
 Reporter:  Den   |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.11
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mads Jensen):

 * has_patch:  0 => 1


Comment:

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

[Django] #27946: Removing unique_together creates invalid migration

2017-03-16 Thread Django

#27946: Removing unique_together creates invalid migration
-+
   Reporter:  Robin Elvin|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Migrations |Version:  1.8
   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 had a model which had a unique_together constraint defined. Now I wish
 to remove this so the unique_together was removed from the model and a
 migration created. When applying the migration the following error
 occurred:

 {{{
   Applying main.0091_auto_20170316_1046...Traceback (most recent call
 last):
   File "manage.py", line 8, in 
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 354, in
 execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 346, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 394, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 445, in execute
 output = self.handle(*args, **options)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 222, in handle
 executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
   File "/usr/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 110, in migrate
 self.apply_migration(states[migration], migration, fake=fake,
 fake_initial=fake_initial)
   File "/usr/local/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 148, in apply_migration
 state = migration.apply(state, schema_editor)
   File "/usr/local/lib/python2.7/site-
 packages/django/db/migrations/migration.py", line 115, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/usr/local/lib/python2.7/site-
 packages/django/db/migrations/operations/models.py", line 359, in
 database_forwards
 getattr(new_model._meta, self.option_name, set()),
   File "/usr/local/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 320, in
 alter_unique_together
 self._delete_composed_index(model, fields, {'unique': True},
 self.sql_delete_unique)
   File "/usr/local/lib/python2.7/site-
 packages/django/db/backends/mysql/schema.py", line 80, in
 _delete_composed_index
 return super(DatabaseSchemaEditor, self)._delete_composed_index(model,
 fields, *args)
   File "/usr/local/lib/python2.7/site-
 packages/django/db/backends/base/schema.py", line 349, in
 _delete_composed_index
 ", ".join(columns),
 ValueError: Found wrong number (0) of constraints for
 main_projectdrivefile(name, directory_id)
 }}}

 The model's Meta before starting which was subsequently removed prior to
 creating the migration:

 {{{
 #!python
 class Meta:
 unique_together = ('name', 'directory')

 }}}

 The migration created looks like this:

 {{{
 #!python
 class Migration(migrations.Migration):

 dependencies = [
 ('main', '0090_auto_20170314_1033'),
 ]

 operations = [
 migrations.AlterUniqueTogether(
 name='projectdrivefile',
 unique_together=set([]),
 ),
 ]
 }}}

 Steps to reproduce:

   1. Create a model with a unique_together constraint
   2. Create a migration for this model with makemigrations
   3. Apply migration
   4. Remove unique_together completely
   5. Create a migration for this model with makemigrations
   6. Apply migration

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

Re: [Django] #27946: Removing unique_together creates invalid migration

2017-03-16 Thread Django

#27946: Removing unique_together creates invalid migration
---+--
 Reporter:  Robin Elvin|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Robin Elvin:

Old description:

> I had a model which had a unique_together constraint defined. Now I wish
> to remove this so the unique_together was removed from the model and a
> migration created. When applying the migration the following error
> occurred:
>
> {{{
>   Applying main.0091_auto_20170316_1046...Traceback (most recent call
> last):
>   File "manage.py", line 8, in 
> execute_from_command_line(sys.argv)
>   File "/usr/local/lib/python2.7/site-
> packages/django/core/management/__init__.py", line 354, in
> execute_from_command_line
> utility.execute()
>   File "/usr/local/lib/python2.7/site-
> packages/django/core/management/__init__.py", line 346, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/usr/local/lib/python2.7/site-
> packages/django/core/management/base.py", line 394, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/usr/local/lib/python2.7/site-
> packages/django/core/management/base.py", line 445, in execute
> output = self.handle(*args, **options)
>   File "/usr/local/lib/python2.7/site-
> packages/django/core/management/commands/migrate.py", line 222, in handle
> executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
>   File "/usr/local/lib/python2.7/site-
> packages/django/db/migrations/executor.py", line 110, in migrate
> self.apply_migration(states[migration], migration, fake=fake,
> fake_initial=fake_initial)
>   File "/usr/local/lib/python2.7/site-
> packages/django/db/migrations/executor.py", line 148, in apply_migration
> state = migration.apply(state, schema_editor)
>   File "/usr/local/lib/python2.7/site-
> packages/django/db/migrations/migration.py", line 115, in apply
> operation.database_forwards(self.app_label, schema_editor, old_state,
> project_state)
>   File "/usr/local/lib/python2.7/site-
> packages/django/db/migrations/operations/models.py", line 359, in
> database_forwards
> getattr(new_model._meta, self.option_name, set()),
>   File "/usr/local/lib/python2.7/site-
> packages/django/db/backends/base/schema.py", line 320, in
> alter_unique_together
> self._delete_composed_index(model, fields, {'unique': True},
> self.sql_delete_unique)
>   File "/usr/local/lib/python2.7/site-
> packages/django/db/backends/mysql/schema.py", line 80, in
> _delete_composed_index
> return super(DatabaseSchemaEditor,
> self)._delete_composed_index(model, fields, *args)
>   File "/usr/local/lib/python2.7/site-
> packages/django/db/backends/base/schema.py", line 349, in
> _delete_composed_index
> ", ".join(columns),
> ValueError: Found wrong number (0) of constraints for
> main_projectdrivefile(name, directory_id)
> }}}
>
> The model's Meta before starting which was subsequently removed prior to
> creating the migration:
>
> {{{
> #!python
> class Meta:
> unique_together = ('name', 'directory')
>
> }}}
>
> The migration created looks like this:
>
> {{{
> #!python
> class Migration(migrations.Migration):
>
> dependencies = [
> ('main', '0090_auto_20170314_1033'),
> ]
>
> operations = [
> migrations.AlterUniqueTogether(
> name='projectdrivefile',
> unique_together=set([]),
> ),
> ]
> }}}
>
> Steps to reproduce:
>
>   1. Create a model with a unique_together constraint
>   2. Create a migration for this model with makemigrations
>   3. Apply migration
>   4. Remove unique_together completely
>   5. Create a migration for this model with makemigrations
>   6. Apply migration

New description:

 I had a model which had a unique_together constraint defined. Now I wish
 to remove this so the unique_together was removed from the model and a
 migration created. When applying the migration the following error
 occurred:

 {{{
   Applying main.0091_auto_20170316_1046...Traceback (most recent call
 last):
   File "manage.py", line 8, in 
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 354, in
 execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 346, in execute
 self.fetch_command(subcommand).run_from_argv(self.ar

Re: [Django] #26423: Make EmailValidator use HTML5 validation rather than more complicated regular expressions

2017-03-16 Thread Django

Comment (by Max Nordlund):

I came across this today and realized that the current regexp, in 1.10.5,
contains a type. At least I think it does, since the opening bracket of
the second range in `user_regex` is escaped, but it shouldn't be.

Anyway, I threw together a small PR to fix that, and I hope it can be
merge to stable until this lands. I also added a bunch of new examples,
and at the very least those should get slurped into the PR from Haris.

See https://github.com/django/django/pull/8187

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

Re: [Django] #27859: Migration to create TextField with db_index=True crashes on MySQL

2017-03-16 Thread Django

#27859: Migration to create TextField with db_index=True crashes on MySQL
--+---
 Reporter:  Daniel Quinn  |Owner:  Zubair Alam
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  mysql | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+---

Comment (by Zubair Alam):

 Have made changes in pull request
 [https://github.com/django/django/pull/8118]

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

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

Re: [Django] #27946: Removing unique_together creates invalid migration

2017-03-16 Thread Django

#27946: Removing unique_together creates invalid migration
-+--
 Reporter:  Robin Elvin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8
 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 Tim Graham):

 * type:  Uncategorized => Bug


Comment:

 Which database are you using? Can you reproduce the issue with Django's
 master branch or a version newer than 1.8?

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

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

Re: [Django] #27945: RegexValidator uses search instead of match

2017-03-16 Thread Django

#27945: RegexValidator uses search instead of match
--+--
 Reporter:  Shubham Jain  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by Tim Graham):

 Where's the documentation you quoted?
 
[https://docs.djangoproject.com/en/dev/ref/validators/#django.core.validators.RegexValidator.regex
 I see], "The regular expression pattern to search for the provided value".
 Presumably the documentation you mentioned should be fixed since changing
 behavior would be backwards incompatible.

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

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships"

2017-03-16 Thread Django

#27936: Add some clarifications to "Spanning multi-valued relationships"
--+
 Reporter:  Thomas Güttler|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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 Tim Graham):

 I'm not convinced that a diagram is advantageous for this but if you want
 to create one, you can get other opinions on the DevelopersMailingList.

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

Re: [Django] #27945: RegexValidator uses search instead of match

2017-03-16 Thread Django

#27945: RegexValidator uses search instead of match
--+--
 Reporter:  Shubham Jain  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by Shubham Jain):

 So the
 
[documentation](https://docs.djangoproject.com/en/dev/ref/validators/#django.core.validators.RegexValidator.regex)
 says, "regex pattern to search for provided value". I suppose this means,
 you try to see if value fits in the regex. But instead it sees if regex
 fits anywhere in the value. So in documentation, it must be "regex pattern
 to search for, in the provided value".

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

Re: [Django] #27946: Removing unique_together creates invalid migration

2017-03-16 Thread Django

Comment (by Robin Elvin):

This is on MySQL.

In the course of trying to recreate this issue I have discovered that the
issue stems from the fact that the table does not have the UNIQUE KEY
currently. I am unsure as to how this has happened but this means that the
table is not consistent with the migrations. I have manually added the
UNIQUE KEY back using ALTER TABLE and successfully applied the migration.

So, I don't know if this is something migrations should handle. Given that
the desired state of the model is in effect what it is currently should it
just ignore the error? Or perhaps the error message should be more
descriptive as this threw me off the scent for quite a while.

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

[Django] #27947: error_messages does not work on SlugField in ModelForm

2017-03-16 Thread Django

#27947: error_messages does not work on SlugField in ModelForm
--+
   Reporter:  Jimmy Merrild Krag  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Uncategorized   |Version:  1.8
   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 have the following field in a model:


 {{{
 reference = models.SlugField(
 max_length=20,
 blank=False, null=False,
 error_messages={
 'invalid': _('A reference may only contain letters, numbers,
 underscores and hyphens.'),
 })
 }}}


 however, when submitting the field in a `ModelForm` with invalid content
 (e.g. containing a space character) the error message is the default one
 for `SlugField` and not the one I set.

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

Re: [Django] #27947: Document that model field error_messages don't carry over to forms (was: error_messages does not work on SlugField in ModelForm)

2017-03-16 Thread Django

#27947: Document that model field error_messages don't carry over to forms
--+
 Reporter:  Jimmy Merrild Krag|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 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 Tim Graham):

 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Accepted
 * type:  Bug => Cleanup/optimization


Comment:

 I was surprised about this behavior but according to
 ticket:13693#comment:10, it's expected. The documentation should clarify
 this.

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

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

Re: [Django] #27947: Document that model field error_messages don't carry over to forms

2017-03-16 Thread Django

#27947: Document that model field error_messages don't carry over to forms
--+
 Reporter:  Jimmy Merrild Krag|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.8
 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 Jimmy Merrild Krag):

 So how should I override my error messages?
 Right now I do
 {{{
 def __init__(self, *args, **kwargs):
 super(MyForm, self).__init__(*args, **kwargs)

 # Correct error message for reference field
 reference_field = Plan._meta.get_field('reference')
 self.fields['reference'].error_messages.update(reference_field.error_messages)
 }}}
 which I think is ugly

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

Re: [Django] #27944: Have meta.get_field('pk') return the primary key field directly

2017-03-16 Thread Django

#27944: Have meta.get_field('pk') return the primary key field directly
-+-
 Reporter:  Josh Schneier|Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josh Schneier):

 * owner:  nobody => Josh Schneier
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 Patch here: https://github.com/django/django/pull/8191

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

[Django] #27948: Static serving views do incorrect unquote()ing of path

2017-03-16 Thread Django

#27948: Static serving views do incorrect unquote()ing of path
---+
   Reporter:  Florian Apolloner|  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  contrib.staticfiles  |Version:  1.10
   Severity:  Normal   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 `views.static.serve()` and `contrib.staticfiles.views()` both `unquote()`
 the `path` which doesn't allow accessing files with names like `%2F.jpg`.

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

Re: [Django] #27948: Static serving views do incorrect unquote()ing of path

2017-03-16 Thread Django

#27948: Static serving views do incorrect unquote()ing of path
-+
 Reporter:  Florian Apolloner|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #27944: Have meta.get_field('pk') return the primary key field directly

2017-03-16 Thread Django

#27944: Have meta.get_field('pk') return the primary key field directly
-+-
 Reporter:  Josh Schneier|Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

2017-03-16 Thread Django

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Forms |  Version:  1.11
 Severity:  Release blocker   |   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

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


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

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

Re: [Django] #27944: Have meta.get_field('pk') return the primary key field directly

2017-03-16 Thread Django

#27944: Have meta.get_field('pk') return the primary key field directly
-+-
 Reporter:  Josh Schneier|Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josh Schneier):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #27890: runtests.py cleanup exception on Python 3.6

2017-03-16 Thread Django

#27890: runtests.py cleanup exception on Python 3.6
-+
 Reporter:  Vytis Banaitis   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

 * version:  master => 1.11
 * severity:  Normal => Release blocker


Comment:

 I looked a little and didn't see an obvious solution besides some import
 rearranging as suggested in the ticket description.

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

Re: [Django] #26886: TECHNICAL_404_TEMPLATE logs an "Exception while resolving variable" warning

2017-03-16 Thread Django

#26886: TECHNICAL_404_TEMPLATE logs an "Exception while resolving variable" 
warning
--+
 Reporter:  None  |Owner:  None
 Type:  Cleanup/optimization  |   Status:  new
Component:  Error reporting   |  Version:  1.9
 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 Tim Graham):

 I started a thread on the [https://groups.google.com/d/topic/django-
 developers/zdULZcmAWNw/discussion django-developers mailing list] to see
 if there might be consensus to remove logging of undefined variables.

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

Re: [Django] #16752: Multi-db without a 'default' database

2017-03-16 Thread Django

#16752: Multi-db without a 'default' database
-+-
 Reporter:  Jeremy Dunck |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Anton Samarchyan:

Old description:

> In the [https://docs.djangoproject.com/en/dev/topics/db/multi-db multi-db
> doc] it says:
> {{{
> If you don’t have a default database, you need to be careful to always
> specify the database that you want to use.
> }}}
>
> I have a project where that is exactly the behavior I'd prefer - I want
> to explicitly route every call and have nothing go to the 'default'
> database.
>
> However, when I removed the 'default' key from DATABASES (and hard-coded
> a router to always return a different value), model validation failed.
> This seems to be because it imports
> {{{
> from django.db import connection
> }}}
> then proceeds to validation the schema against that connection (which is,
> in fact, the non-existant 'default').  This fails as soon as an operation
> is called on the connection.
>
> There is a second problem with this -- all model validation occurs
> against the default connection rather than the connection that the model
> will be routed to.  That seems like a bug, but I'd like to treat it
> separately.
>
> My intention with this ticket is to establish: do we intend projects to
> work without a 'default' project, as implied by the docs, or is a
> 'default' database always assumed?

New description:

 In the [https://docs.djangoproject.com/en/dev/topics/db/multi-db multi-db
 doc] it says:
 {{{
 If you don’t have a default database, you need to be careful to always
 specify the database that you want to use.
 }}}

 I have a project where that is exactly the behavior I'd prefer - I want to
 explicitly route every call and have nothing go to the 'default' database.

 However, when I removed the 'default' key from DATABASES (and hard-coded a
 router to always return a different value), model validation failed.  This
 seems to be because it imports
 {{{
 from django.db import connection
 }}}
 then proceeds to validation the schema against that connection (which is,
 in fact, the nonexistent 'default').  This fails as soon as an operation
 is called on the connection.

 There is a second problem with this -- all model validation occurs against
 the default connection rather than the connection that the model will be
 routed to.  That seems like a bug, but I'd like to treat it separately.

 My intention with this ticket is to establish: do we intend projects to
 work without a 'default' project, as implied by the docs, or is a
 'default' database always assumed?

--

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

[Django] #27949: GeoDjango - map widget toolbar disapeared in admin

2017-03-16 Thread Django

#27949: GeoDjango - map widget toolbar disapeared in admin
---+
   Reporter:  elky |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  GIS  |Version:  1.11
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Previously map widget had a toolbar with some controls like draw polygon,
 move map, etc. This toolbar disappeared in 1.11 now.
 This issue is probably related with
 [https://code.djangoproject.com/ticket/27939 #27939]
 Screenshots attached.

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

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

Re: [Django] #27949: GeoDjango - map widget toolbar disapeared in admin

2017-03-16 Thread Django

#27949: GeoDjango - map widget toolbar disapeared in admin
-+--
 Reporter:  elky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Release blocker  |   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 elky):

 * Attachment "django-1.10-map-toolbar.jpg" added.

 Django 1.10 - map widget has a toolbar

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

Re: [Django] #27949: GeoDjango - map widget toolbar disapeared in admin

2017-03-16 Thread Django

#27949: GeoDjango - map widget toolbar disapeared in admin
-+--
 Reporter:  elky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Release blocker  |   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 elky):

 * Attachment "django-1.11-map-no-toolbar.jpg" added.

 Django 1.11 - map widget without toolbar

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

[Django] #27950: Permission classes for Class Based Views

2017-03-16 Thread Django

#27950: Permission classes for Class Based Views
-+-
   Reporter:  Piotr  |  Owner:  nobody
  Szpetkowski|
   Type:  New| Status:  new
  feature|
  Component:  Generic|Version:  master
  views  |   Keywords:  permissions, view,
   Severity:  Normal |  cbv
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I would like to propose to add support for permission classes for generic
 views (CBV) to make it simpler to add custom requirements per specific
 view. Syntax could be based on what is done inside DRF at the moment, so
 setting it up at the view level it would be very simple and convenient:
 {{{#!python
 class CustomView(View):
 permission_classes = (IsAuthenticated, IsReadOnly)
 }}}
 That would evaluate to `IsAuthenticated AND IsReadOnly`. I'm not entirely
 sure however what syntax should support `IsAuthenticated OR IsReadOnly`.
 One of possible ways is to write one permission class for both conditions
 called `IsAuthenticatedOrReadOnly` (it's the way DRF is doing it), however
 it does not sound like the best solution. I suppose that a proper (but not
 100% pythonic) way to handle such cases would be to override some
 operators (e.g. bitwise or - that's what `Q` object does):
 {{{#!python
 class CustomView(View):
 permission_classes = (IsAuthenticated | IsReadOnly,)
 }}}
 I suppose that it would be nice to be able to provide list for
 `permission_classes` as well if anyone would like to do so:
 {{{#!python
 class CustomView(View):
 permission_classes = [IsAuthenticated]
 }}}
 In case of not meeting requirements of `permission_classes` it might
 simply return 403 Forbidden response (with a possibility to provide custom
 template and maybe also completely override the behavior method?)

 Thanks to OOP custom permission classes might and should be very simple
 (just like in DRF):
  {{{#!python
 class IsAuthenticated(BasePermission):
 def has_permission(self, request, view):
 return request.user and request.user.is_authenticated
 }}}
 It's true that similar behavior can be achieved using decorators, however
 in my opinion decorator syntax is more complicated than a single class
 attribute. Let's keep in mind that simple is better than complex. I'd
 gladly start working on it if it turns out to be a good idea. In fact -
 I've done something alike I've described in here for one of commercial
 projects and it works great.

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

Re: [Django] #27895: Test Client fails to decode json response with unicode characters

2017-03-16 Thread Django

Comment (by Aniruddha Maru):

Tim, it's really straightforward: we have browser based API documentation,
and unicode data. Since json supports utf-8 encoding, it's pretty standard
to always return unicode, rather than have an encode-decode cycle.

Here's some more context of other people who've talked about this bug:
https://github.com/tomchristie/django-rest-framework/issues/2891
https://github.com/tomchristie/django-rest-
framework/issues/2891#issuecomment-178932902

Django rest framework also offers a flag to disable this behavior:
http://www.django-rest-framework.org/api-guide/settings/#unicode_json,
which is enabled by default.

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

Re: [Django] #27895: Test Client fails to decode json response with unicode characters

2017-03-16 Thread Django

#27895: Test Client fails to decode json response with unicode characters
-+-
 Reporter:  Aniruddha Maru   |Owner:  Aniruddha
 |  Maru
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Okay, thanks. Can you create the pull request against stable/1.11.x? I
 think you could modify the existing json view to return some non-ASCII
 content rather than adding another view.

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

Re: [Django] #27949: GeoDjango - map widget toolbar disapeared in admin

2017-03-16 Thread Django

#27949: GeoDjango - map widget toolbar disapeared in admin
-+
 Reporter:  elky |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

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

Re: [Django] #27950: Permission classes for Class Based Views

2017-03-16 Thread Django

#27950: Permission classes for Class Based Views
-+-
 Reporter:  Piotr Szpetkowski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  permissions, view,   | Triage Stage:
  cbv|  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 Will move to accepted if the [https://groups.google.com/d/topic/django-
 developers/E_Ajn2F8MNY/discussion django-developers thread] yields a
 consensus to move forward with 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/075.3f9428a2aeef7a6a6edb17d8ee09bf65%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27946: Improve "ValueError: Found wrong number of constraints" error message (was: Removing unique_together creates invalid migration)

2017-03-16 Thread Django

#27946: Improve "ValueError: Found wrong number of constraints" error message
--+
 Reporter:  Robin Elvin   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  1.8
 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 Tim Graham):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Perhaps the error message could be improved. I've seen several tickets
 reporting this error message as a bug in Django when as you mentioned, it
 really has to do with the fact that the database is in an unexpected
 state.

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

Re: [Django] #27945: Clarify RegexValidator docs (match vs. search) (was: RegexValidator uses search instead of match)

2017-03-16 Thread Django

#27945: Clarify RegexValidator docs (match vs. search)
--+
 Reporter:  Shubham Jain  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Bug => Cleanup/optimization
 * has_patch:  1 => 0
 * stage:  Unreviewed => Accepted
 * component:  Core (Other) => Documentation


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.b308835fc7bcdca8b1c2dbba71188d7c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27675: Django postgres JSONField encoding

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships"

[Django] #27945: RegexValidator uses search instead of match

Re: [Django] #27945: RegexValidator uses search instead of match

Re: [Django] #27935: BrinIndex.suffix for postgres longer 3 char

[Django] #27946: Removing unique_together creates invalid migration

Re: [Django] #27946: Removing unique_together creates invalid migration

Re: [Django] #26423: Make EmailValidator use HTML5 validation rather than more complicated regular expressions

Re: [Django] #27859: Migration to create TextField with db_index=True crashes on MySQL

Re: [Django] #27946: Removing unique_together creates invalid migration

Re: [Django] #27945: RegexValidator uses search instead of match

Re: [Django] #27936: Add some clarifications to "Spanning multi-valued relationships"

Re: [Django] #27945: RegexValidator uses search instead of match

Re: [Django] #27946: Removing unique_together creates invalid migration

[Django] #27947: error_messages does not work on SlugField in ModelForm

Re: [Django] #27947: Document that model field error_messages don't carry over to forms (was: error_messages does not work on SlugField in ModelForm)

Re: [Django] #27947: Document that model field error_messages don't carry over to forms

Re: [Django] #27944: Have meta.get_field('pk') return the primary key field directly

[Django] #27948: Static serving views do incorrect unquote()ing of path

Re: [Django] #27948: Static serving views do incorrect unquote()ing of path

Re: [Django] #27944: Have meta.get_field('pk') return the primary key field directly

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

Re: [Django] #27944: Have meta.get_field('pk') return the primary key field directly

Re: [Django] #27890: runtests.py cleanup exception on Python 3.6

Re: [Django] #26886: TECHNICAL_404_TEMPLATE logs an "Exception while resolving variable" warning

Re: [Django] #16752: Multi-db without a 'default' database

[Django] #27949: GeoDjango - map widget toolbar disapeared in admin

Re: [Django] #27949: GeoDjango - map widget toolbar disapeared in admin

Re: [Django] #27949: GeoDjango - map widget toolbar disapeared in admin

[Django] #27950: Permission classes for Class Based Views

Re: [Django] #27895: Test Client fails to decode json response with unicode characters

Re: [Django] #27895: Test Client fails to decode json response with unicode characters

Re: [Django] #27949: GeoDjango - map widget toolbar disapeared in admin

Re: [Django] #27950: Permission classes for Class Based Views

Re: [Django] #27946: Improve "ValueError: Found wrong number of constraints" error message (was: Removing unique_together creates invalid migration)

Re: [Django] #27945: Clarify RegexValidator docs (match vs. search) (was: RegexValidator uses search instead of match)

36 matches

Site Navigation

Mail list logo

Footer information