date:20140424

Re: [Django] #22504: Wrong terminology (TLD/SLD) in docs: /topics/security/

2014-04-24 Thread Django

#22504: Wrong terminology (TLD/SLD) in docs: /topics/security/
---+
 Reporter:  chris@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by chris@…):

 * needs_better_patch:  1 => 0


Comment:

 Agreed, updated. I left the option of serving from a different top-level
 domain in, but reverted the addition of an example for that.

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

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

Re: [Django] #22512: Adding auto_now field to model causes migrate exception

2014-04-24 Thread Django

#22512: Adding auto_now field to model causes migrate exception
-+--
 Reporter:  jaddison |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7-beta-1
 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
-+--

Comment (by loic84):

 I believe this was fixed with 074d3183d92cd5ed5da8f51e7048b12a96f55e0a,
 could you try the master branch?

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

Re: [Django] #22512: Adding auto_now field to model causes migrate exception

2014-04-24 Thread Django

#22512: Adding auto_now field to model causes migrate exception
-+--
 Reporter:  jaddison |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7-beta-1
 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 jaddison):

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


Comment:

 As an additional note, would it not be wise to use `timezone.now()` if
 time zone support is active? (see
 https://docs.djangoproject.com/en/1.7/topics/i18n/timezones/#naive-and-
 aware-datetime-objects)

 After fixing the migration to use `datetime.datetime(...)` in the original
 bug report, the migration runs fine, however I get this warning:

 {{{
   ...
   Applying
 
content.0003_contentlink_updated.../Users/jaddison/.virtualenvs/project1/lib/python2.7
 /site-packages/django/db/backends/sqlite3/base.py:63: RuntimeWarning:
 SQLite received a naive datetime (2014-04-25 04:32:56.089929) while time
 zone support is active.
   RuntimeWarning)
 }}}

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

[Django] #22512: Adding auto_now field to model causes migrate exception

2014-04-24 Thread Django

#22512: Adding auto_now field to model causes migrate exception
-+
 Reporter:  jaddison |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Migrations   |Version:  1.7-beta-1
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I have a feeling this bug has already been filed, but I couldn't (easily)
 find it.

 It looks like the makemigrations command is failing to import (or use) the
 datetime module properly. My steps:

 * On an existing model, add a DateTimeField with `auto_now=True` set
 * Run `makemigrations` command
 * Run `migrate` command

 Result is an exception, detailed below.

 Calling makemigrations:

 {{{
 (project1)jaddison@jamess-air-2:~/projects/project1 (master)$ ./manage.py
 makemigrations
 You are trying to add a non-nullable field 'updated' to contentlink
 without a default;
 we can't do that (the database needs something to populate existing rows).
 Please select a fix:
  1) Provide a one-off default now (will be set on all existing rows)
  2) Quit, and let me add a default in models.py
 Select an option: 1
 Please enter the default value now, as valid Python
 The datetime module is available, so you can do e.g. datetime.date.today()
 >>> datetime.datetime.now()
 Migrations for 'content':
   0003_contentlink_updated.py:
 - Add field updated to contentlink
 }}}

 Calling migrate:

 {{{
 (project1)jaddison@jamess-air-2:~/projects/project1 (master)$ ./manage.py
 migrate
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 427, in
 execute_from_command_line
 utility.execute()
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 419, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/core/management/base.py", line 288, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/core/management/base.py", line 337, in execute
 output = self.handle(*args, **options)
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 62, in handle
 executor = MigrationExecutor(connection,
 self.migration_progress_callback)
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 14, in __init__
 self.loader = MigrationLoader(self.connection)
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/db/migrations/loader.py", line 48, in __init__
 self.build_graph()
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/db/migrations/loader.py", line 145, in build_graph
 self.load_disk()
   File "/Users/jaddison/.virtualenvs/project1/lib/python2.7/site-
 packages/django/db/migrations/loader.py", line 103, in load_disk
 migration_module = import_module("%s.%s" % (module_name,
 migration_name))
   File
 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
 line 37, in import_module
 __import__(name)
   File
 
"/Users/jaddison/projects/project1/content/migrations/0003_contentlink_updated.py",
 line 6, in 
 class Migration(migrations.Migration):
   File
 
"/Users/jaddison/projects/project1/content/migrations/0003_contentlink_updated.py",
 line 16, in Migration
 field=models.DateTimeField(default=datetime(2014, 4, 25, 4, 32, 56,
 89929), auto_now=True),
 TypeError: 'module' object is not callable
 }}}

 The contents of the generated migration `0003_contentlink_updated.py`:

 {{{
 # encoding: utf8
 from django.db import models, migrations
 import datetime


 class Migration(migrations.Migration):

 dependencies = [
 ('content', '0002_contentlink_body'),
 ]

 operations = [
 migrations.AddField(
 model_name='contentlink',
 name='updated',
 field=models.DateTimeField(default=datetime(2014, 4, 25, 4,
 32, 56, 89929), auto_now=True),
 preserve_default=False,
 ),
 ]
 }}}

 Note that it should be `default=datetime.datetime(2014, 4, 25, 4, 32, 56,
 89929)` instead.

-- 
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

Re: [Django] #10523: Changing object with long repr causes error

2014-04-24 Thread Django

#10523: Changing object with long __repr__ causes error
---+-
 Reporter:  bromer |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.2-beta
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by shai):

 @hodzanassredin: I suspect you're running into #22305 -- please check the
 character-set of your database.

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

Re: [Django] #22483: Oracle test failures due to InterfaceError

2014-04-24 Thread Django

#22483: Oracle test failures due to InterfaceError
-+-
 Reporter:  timo |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 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 shai):

 I feel a little uneasy about  25209715d44562dcbf26f04ed9e0d19ee3c2aa84. I
 think ignoring all backend errors in `close()`, on all backends, may hide
 real problems. For the purpose of this ticket,
 53d97e4fe300f2775b5bb1b8010ec415994fa105 serves the same purpose with much
 narrower focus; more generally, I think we should only catch
 `connection.features.closed_cursor_error_class` -- I don't think we can
 reasonably say that any other error should be silenced.

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

[django/django] 7421e1: [1.7.x] Made sure cursor.close() does not complain...

2014-04-24 Thread GitHub

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 7421e1e320fc46a52af0a1e4518b0ce4344c1a0f
  
https://github.com/django/django/commit/7421e1e320fc46a52af0a1e4518b0ce4344c1a0f
  Author: Shai Berger 
  Date:   2014-04-25 (Fri, 25 Apr 2014)

  Changed paths:
M django/db/backends/oracle/base.py

  Log Message:
  ---
  [1.7.x] Made sure cursor.close() does not complain if cursor is already 
closed on Oracle

Refs #22483

Backport of 53d97e4fe3 from master


  Commit: b8b179bbf50f8ec3e2102f7109c594cb1ba85e93
  
https://github.com/django/django/commit/b8b179bbf50f8ec3e2102f7109c594cb1ba85e93
  Author: Shai Berger 
  Date:   2014-04-25 (Fri, 25 Apr 2014)

  Changed paths:
M django/db/backends/schema.py

  Log Message:
  ---
  [1.7.x] Fixed #22498 -- constraint name was not quoted in FK creation SQL

Backport of 843613add4 from master


Compare: https://github.com/django/django/compare/bee118a7011b...b8b179bbf50f

-- 
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/535992f284c3f_27d113a9d4056896%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22498: Oracle test failure in migrations: identifier is too long

2014-04-24 Thread Django

#22498: Oracle test failure in migrations: identifier is too long
-+--
 Reporter:  timo |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:  fixed
 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 Shai Berger ):

 In [changeset:"843613add4d5e7493140fedd10c40c41706b68a8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="843613add4d5e7493140fedd10c40c41706b68a8"
 Fixed #22498 -- constraint name was not quoted in FK creation SQL
 }}}

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

Re: [Django] #22498: Oracle test failure in migrations: identifier is too long

2014-04-24 Thread Django

#22498: Oracle test failure in migrations: identifier is too long
-+--
 Reporter:  timo |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:  fixed
 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 Shai Berger ):

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


Comment:

 In [changeset:"b8b179bbf50f8ec3e2102f7109c594cb1ba85e93"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b8b179bbf50f8ec3e2102f7109c594cb1ba85e93"
 [1.7.x] Fixed #22498 -- constraint name was not quoted in FK creation SQL

 Backport of 843613add4 from master
 }}}

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

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

[django/django] 53d97e: Made sure cursor.close() does not complain if curs...

2014-04-24 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 53d97e4fe300f2775b5bb1b8010ec415994fa105
  
https://github.com/django/django/commit/53d97e4fe300f2775b5bb1b8010ec415994fa105
  Author: Shai Berger 
  Date:   2014-04-25 (Fri, 25 Apr 2014)

  Changed paths:
M django/db/backends/oracle/base.py

  Log Message:
  ---
  Made sure cursor.close() does not complain if cursor is already closed on 
Oracle

Refs #22483


  Commit: 843613add4d5e7493140fedd10c40c41706b68a8
  
https://github.com/django/django/commit/843613add4d5e7493140fedd10c40c41706b68a8
  Author: Shai Berger 
  Date:   2014-04-25 (Fri, 25 Apr 2014)

  Changed paths:
M django/db/backends/schema.py

  Log Message:
  ---
  Fixed #22498 -- constraint name was not quoted in FK creation SQL


Compare: https://github.com/django/django/compare/25209715d445...843613add4d5

-- 
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/535992f316fb2_1f3e61bd40589e4%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22483: Oracle test failures due to InterfaceError

2014-04-24 Thread Django

#22483: Oracle test failures due to InterfaceError
-+-
 Reporter:  timo |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 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 Shai Berger ):

 In [changeset:"53d97e4fe300f2775b5bb1b8010ec415994fa105"]:
 {{{
 #!CommitTicketReference repository=""
 revision="53d97e4fe300f2775b5bb1b8010ec415994fa105"
 Made sure cursor.close() does not complain if cursor is already closed on
 Oracle

 Refs #22483
 }}}

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

[Django] #22511: Usage help of makemigrations command missing argument for app

2014-04-24 Thread Django

#22511: Usage help of makemigrations command missing argument for app
--+
 Reporter:  bruno.devpod@…|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Migrations|Version:  1.7-beta-2
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The makemigrations command usage help shoud show:

 Usage: manage.py makemigrations [options] [app_label]

 Instead of:

 Usage: manage.py makemigrations [options]

 As pointed in documentation:

 If your app already has models and database tables, and doesn’t have
 migrations yet (for example, you created it against a previous Django
 version), you’ll need to convert it to use migrations; this is a simple
 process:

 $ python manage.py makemigrations your_app_label

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

[Django] #22510: Form fields cannot have names that are present as attributes on the form

2014-04-24 Thread Django

#22510: Form fields cannot have names that are present as attributes on the form
+
 Reporter:  gc@…|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.7-beta-2
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+
 This was broken in #8620. Fixing this is impossible, unless shadowing is
 only enabled for None, at which point the fix becomes trivial (
 
https://github.com/gcbirzan/django/commit/f62f991444610ebadad809981d9a037298a660db
 ).

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

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

Re: [Django] #22504: Wrong terminology (TLD/SLD) in docs: /topics/security/

2014-04-24 Thread Django

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

Comment:

This is definitely a mistake, and something we should improve. The only
thing I'm not sure about is the specific suggestion to have the Django app
on example.com, and the user content on example.net. Although this will
certainly work, it's a lot less obvious. In most cases, users who own both
example.net and example.com would redirect one to the other. So this feels
more error-prone. Perhaps we should leave the examples as they are
currently.

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

Re: [Django] #22485: makemigrations fails with dependencies to unmigrated apps

2014-04-24 Thread Django

#22485: makemigrations fails with dependencies to unmigrated apps
-+-
 Reporter:  apollo13 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations,  | Triage Stage:  Accepted
  unmigrated, makemigrations |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by rypalmer):

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

[Django] #22509: New Feature: Add new signals for django.contrib.auth's password change/reset

2014-04-24 Thread Django

#22509: New Feature: Add new signals for django.contrib.auth's password
change/reset
--+
 Reporter:  xiaohanyu |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.auth  |Version:  master
 Severity:  Normal|   Keywords:  auth, password, signal
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hi, guys:

 I'm a newbie in Django communities. I was wondering is it reasonable to
 add some signals to django.contrib.auth's password change/reset
 procedures. For example, we can send signals when user reset/change his
 password.

 I need this since recent days I was doing a project with django-
 registration, while I need to store password in two different places, one
 in django.contrib.auth, the other in another place.

 If it is reasonable, I think I can provide a patch for this.

 Thanks.

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

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

Re: [Django] #22497: Documentation for deconstruct is wrong

2014-04-24 Thread Django

#22497: Documentation for deconstruct is wrong
---+--
 Reporter:  reames@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.7-beta-2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by nliberg):

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


Comment:

 I too was confused by this at first.
 For Fields a 4-tuple including the field name is returned. Documented
 here: https://docs.djangoproject.com/en/1.7/howto/custom-model-fields
 /#field-deconstruction
 For other custom classes a 3-tuple is returned. Documented here:
 https://docs.djangoproject.com/en/1.7/topics/migrations/#custom-
 deconstruct-method

 The latter text should probably mention and link to the former.

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

[Django] #22508: select_related on a foreign related object fails to load fields on original object

2014-04-24 Thread Django

#22508: select_related on a foreign related object fails to load fields on 
original
object
--+
 Reporter:  boxm  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Consider these models:

 {{{
 class Show(models.Model):
 pass


 class Poll(models.Model):
 event = models.ForeignKey('Event')


 class Event(models.Model)
 show = models.ForeignKey(Show)
 }}}

 The following code fails to load the poll.event.show attribute:

 {{{
 In [3]: event = Event.objects.all()[2]

 In [4]: poll = event.poll_set.select_related('event',
 'event__show').all()[0]

 In [5]: hasattr(poll.event, '_show_cache')
 Out[5]: False

 }}}

 For comparison, in 1.4 the same code produces:

 {{{
 In [12]: event = Event.objects.all()[2]

 In [13]: poll = event.poll_set.select_related('event',
 'event__show').all()[0]

 In [14]: hasattr(poll.event, '_show_cache')
 Out[14]: True
 }}}

 The bug appears to be in the known_objects code around line 247 in
 db/models/query.py which looks like it will overwrite the poll.event
 attribute that was just retrieved from the DB (via select_related) and
 replaces it with the parent model, which in this case doesn't have the
 show attribute loaded.

 Since the ORM was explicitly instructed to load the Event model in the
 call, it shouldn't then replace the poll.event attribute with the
 previously-known parent 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/047.d78e39567c4b8a35fb3c70abe2919202%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22506: SSL cert for *.djangoproject.com expires 5/3/14

2014-04-24 Thread Django

#22506: SSL cert for *.djangoproject.com expires 5/3/14
-+
 Reporter:  jnovinger|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  *.djangoproject.com  |  Version:
 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 bmispelon):

 * needs_better_patch:   => 0
 * component:  Uncategorized => *.djangoproject.com
 * needs_tests:   => 0
 * version:  1.6 =>
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 I'm not sure either what the correct channel for reporting this would be
 so this will do.

 Thanks for bringing this to our attention.

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

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

[Django] #22507: Sending signal documentation is misleading

2014-04-24 Thread Django

#22507: Sending signal documentation is misleading
+
   Reporter:  claudep   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 In the documentation of sending signals
 (https://docs.djangoproject.com/en/dev/topics/signals/#sending-signals),
 there is an example where the sender parameter is filled with `self` (an
 instance), while most of the time, sender should be a class (at least it's
 the case in Django's own source code).

 Unless I'm misunderstanding something, I suggest to replace `sender=self`
 by `sender=self.__class__` in the example. And maybe specify that sender
 is a class most of the time. I can do the change if someone confirms that
 issue.

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

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

Re: [Django] #22505: Create an Admin editable list

2014-04-24 Thread Django

#22505: Create an Admin editable list
---+--
 Reporter:  radsepvj@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.6
 Severity:  Normal |   Resolution:  invalid
 Keywords:  editable list  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by charettes):

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


Comment:

 This ticket tracker is not a support channel, see
 TicketClosingReasons/UseSupportChannels.

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

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

[Django] #22506: SSL cert for *.djangoproject.com expires 5/3/14

2014-04-24 Thread Django

#22506: SSL cert for *.djangoproject.com expires 5/3/14
---+
 Reporter:  jnovinger  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The current SSL cert for '*.djangoproject.com' expires on 5/3/14. In
 addition, the cert does not specify an 'Organization' (O) or
 'Organizational Unit' (OU), which may or may not be useful.

 Apologies if this is not the correct place for this, I did a quick search
 of django-developers, django-users, and Trac, but didn't find any previous
 discussion. I assume there is a team that administers the various
 *.djangoproject.com infrastructure, but didn't find any info in my quick
 search.

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

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

[Django] #22505: Create an Admin editable list

2014-04-24 Thread Django

#22505: Create an Admin editable list
---+---
 Reporter:  radsepvj@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:  editable list
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 Could you please update on How to create a admin-editable list [check-
 list] in django? Thank you, Rads

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

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

Re: [Django] #22421: Loading fixtures with one-to-one inheritance and M2M with natural keys fails since 1.7 Beta (was: Loading fixtures with OneToOne relation and natural keys fails since 1.7 Beta)

2014-04-24 Thread Django

#22421: Loading fixtures with one-to-one inheritance and M2M with natural keys
fails since 1.7 Beta
-+-
 Reporter:  stanislas.guerra@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core |  Version:  master
  (Serialization)|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by stanislas.guerra@…):

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


Comment:

 Looks like it came from this commit in
 
''django/db/models/fields/related.py#ForeignObject.get_instance_value_for_fields(instance,
 fields)'' :

 
https://github.com/django/django/commit/244e2b71f512605f3d0a8e1ba4c9d6b538acf69d#diff-301
 Which is related to the ticket #20820

 {{{

 -ret.append(instance.pk)
 -else:
 -ret.append(getattr(instance, field.attname))
 +possible_parent_link =
 opts.get_ancestor_link(field.model)
 +if not possible_parent_link or
 possible_parent_link.primary_key:
 +ret.append(instance.pk)
 +continue
 +ret.append(getattr(instance, field.attname))
  return tuple(ret)
 }}}

 And especially the last line: `ret.append(getattr(instance,
 field.attname))` (`.id` in that case) which add a `None` to
 the returned Tuple raising an Exception in `create_many_related_manager()`
 :

 {{{
   self.related_val =
 source_field.get_foreign_related_value(instance)
 if None in self.related_val:
 raise ValueError('"%r" needs to have a value for field
 "%s" before '
  'this many-to-many relationship can be
 used.' %
  (instance, source_field_name))


 }}}

 Because the Assistant object has not been saved yet.

 FYI, the fixture loading fails when trying to save the ''Assistant''
 object (which is a one-to-one to ''User'') because of the M2M
 ''user_permissions'' relation.

 Hope this helps.

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

Re: [Django] #22504: Wrong terminology (TLD/SLD) in docs: /topics/security/

2014-04-24 Thread Django

#22504: Wrong terminology (TLD/SLD) in docs: /topics/security/
---+--
 Reporter:  chris@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 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 chris@…):

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

Re: [Django] #22480: "django-admin.py dumpdata" - unable to serialize

2014-04-24 Thread Django

#22480: "django-admin.py dumpdata" - unable to serialize
---+--
 Reporter:  yn |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.6
 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 timshaffer):

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


Comment:

 Do you get any extra output if you run it with traceback?

 {{{
 manage.py dumpdata --traceback > data.json
 }}}

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

[Django] #22504: Wrong terminology (TLD/SLD) in docs: /topics/security/

2014-04-24 Thread Django

#22504: Wrong terminology (TLD/SLD) in docs: /topics/security/
---+
Reporter: chris@…| Owner: nobody
Type: Bug| Status: new
Component: Documentation |Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 1 | UI/UX: 0
---+
/topics/security says about leveraging the same-origin policy:

One class of attacks can be prevented by always serving user uploaded
content from a distinct Top Level Domain (TLD). This prevents any exploit
blocked by same-origin policy protections such as cross site scripting.
For example, if your site runs on example.com, you would want to serve
uploaded content (the MEDIA_URL setting) from something like usercontent-
example.com. It’s not sufficient to serve content from a subdomain like
usercontent.example.com.

The term "Top Level Domain" is wrong and should be replaced by "second-
level domain". In this example, the TLD is .com, but the example
emphasizes the difference between "example.com" and "usercontent-
example.com", which are different SLDs sharing the same TLD.

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

Re: [Django] #22267: django.utils.html.smart_urlquote() is incorrectly unquoting the url

2014-04-24 Thread Django

#22267: django.utils.html.smart_urlquote() is incorrectly unquoting the url
---+
 Reporter:  meenzam@…  |Owner:  ienzam
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by meenzam@…):

 Any update?

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

[django/django] b0f4ee: Ignored repeated calls to connection.close().

2014-04-24 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b0f4eecfa74a71ec3e968df21d0ac6658ec03d8c
  
https://github.com/django/django/commit/b0f4eecfa74a71ec3e968df21d0ac6658ec03d8c
  Author: Aymeric Augustin 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M django/db/backends/__init__.py

  Log Message:
  ---
  Ignored repeated calls to connection.close().

Forwardport of 9bbb43dd1a from stable/1.7.x


  Commit: 25209715d44562dcbf26f04ed9e0d19ee3c2aa84
  
https://github.com/django/django/commit/25209715d44562dcbf26f04ed9e0d19ee3c2aa84
  Author: Aymeric Augustin 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M django/db/backends/utils.py

  Log Message:
  ---
  Prevented a crash in the cursor wrappers on Oracle.

Fixed #22483 (again).

Forwardport of 5cd6429620 from stable/1.7.x


Compare: https://github.com/django/django/compare/d238c5891239...25209715d445

-- 
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/53590e527b43e_270ca2bd409393%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22483: Oracle test failures due to InterfaceError

2014-04-24 Thread Django

#22483: Oracle test failures due to InterfaceError
-+-
 Reporter:  timo |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"25209715d44562dcbf26f04ed9e0d19ee3c2aa84"]:
 {{{
 #!CommitTicketReference repository=""
 revision="25209715d44562dcbf26f04ed9e0d19ee3c2aa84"
 Prevented a crash in the cursor wrappers on Oracle.

 Fixed #22483 (again).

 Forwardport of 5cd6429620 from stable/1.7.x
 }}}

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

Re: [Django] #10523: Changing object with long repr causes error

2014-04-24 Thread Django

#10523: Changing object with long __repr__ causes error
---+-
 Reporter:  bromer |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.2-beta
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by hodzanassredin@…):

 Can reproduce this bug: object.description = "RT @NPancheewa: "B.A.P
 ถึงอย่างปลอดภัยแล้วค่ะ" กูรอประโยคนี้ทุกครั้งที่มีการเดินทาง #비에이피
 "
 description = models.TextField()
 def __unicode__(self):
 return self.description

 When I'm trying to remove it shows:
 value too long for type character varying(200)

 Environment:


 Request Method: POST
 Request URL: http://127.0.0.1:8000/admin/pins/pin/342/delete/

 Django Version: 1.6.2
 Python Version: 2.7.5
 Installed Applications:
 ('django.contrib.admin',
  'django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.messages',
  'django.contrib.staticfiles',
  'django.contrib.gis',
  'leaflet',
  'djgeojson',
  'storages',
  'social.apps.django_app.default',
  'django_extensions',
  'endless_pagination',
  'haystack',
  'imagekit',
  'auth',
  'pins')
 Installed Middleware:
 ('django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.common.CommonMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware',
  'django.middleware.clickjacking.XFrameOptionsMiddleware')


 Traceback:
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/core/handlers/base.py" in get_response
   114. response = wrapped_callback(request,
 *callback_args, **callback_kwargs)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/contrib/admin/options.py" in wrapper
   432. return self.admin_site.admin_view(view)(*args,
 **kwargs)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/utils/decorators.py" in _wrapped_view
   99. response = view_func(request, *args, **kwargs)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/views/decorators/cache.py" in _wrapped_view_func
   52. response = view_func(request, *args, **kwargs)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/contrib/admin/sites.py" in inner
   198. return view(request, *args, **kwargs)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/utils/decorators.py" in _wrapper
   29. return bound_func(*args, **kwargs)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/utils/decorators.py" in _wrapped_view
   99. response = view_func(request, *args, **kwargs)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/utils/decorators.py" in bound_func
   25. return func(self, *args2, **kwargs2)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/db/transaction.py" in inner
   339. return func(*args, **kwargs)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/contrib/admin/options.py" in delete_view
   1463. self.log_deletion(request, obj, obj_display)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/contrib/admin/options.py" in log_deletion
   632. action_flag=DELETION
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/contrib/admin/models.py" in log_action
   20. e.save()
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/db/models/base.py" in save
   545.force_update=force_update,
 update_fields=update_fields)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/db/models/base.py" in save_base
   573. updated = self._save_table(raw, cls, force_insert,
 force_update, using, update_fields)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/db/models/base.py" in _save_table
   654. result = self._do_insert(cls._base_manager, using,
 fields, update_pk, raw)
 File "/home/hodza/projects/pinstream/venv/local/lib/python2.7/site-
 packages/django/db/models/base.py" in _do_insert

[Django] #22503: Inconsistent behavior when a QuerySet is sliced

2014-04-24 Thread Django

#22503: Inconsistent behavior when a QuerySet is sliced
--+
 Reporter:  ajaest|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.6
 Severity:  Normal|   Keywords:  QuerySet,
 Triage Stage:  Unreviewed|  filter, slice
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 I think that the current behavior of the QuerySet.slice method is not
 consistent. Just an example:

 {{{

 def limited_filtering(max_results=10, *args, **kwargs){
 """
 Returns a Queryset
 """

 returns SomeModel.filter(*args, **kwargs)[:max_results]
 }

 # ...

 def other_method_somewhere(queryset){
 """
 Expects a Queryset of SomeModel and returns the same Queryset filtered
 again
 """

 return queryset.filter(some_other_criteria)
 }

 other_method_somewhere(limited_filtering(*args, **kwargs)); # raises
 "AssertionError: Cannot filter a query once a slice has been taken."
 }}}

 Given the previous code, it is legit and fair that
 `other_method_somewhere` expects, as in most situations, a filtrable
 `QuerySet`. Not allowing a sliced `QuerySet` to be filtered after being
 sliced adds an edge case difficult to handle when methods using a
 `QuerySet` type are somehow semantically far away from each other (and
 thus, they don't know if the other is returning an sliced QuerySet).

 Without knowing the exact reasons why this was implemented this way, the
 possible solutions I can come with are:

  * The most natural one, to make the sliced `QuerySet`s filtrable.
  * To make all the returned query sets in which `can_filter == False` to
 return a new type of `QuerySet`, something like `InmutableQuerySet` in
 order to take advantage of other methods related to them (`values_list`,
 etc.).
  * To make `QuerySet`'s slices return list or other type of collection (I
 guess this is impossible without breaking backwards compatibility).

 Actually, the last case is supposedly the way one would expect it to work
 according to the documentation:


 https://docs.djangoproject.com/en/dev/ref/models/querysets/#when-
 querysets-are-evaluated
   > '''Slicing'''. As explained in Limiting QuerySets, a QuerySet can be
 sliced, using Python’s array-slicing syntax. Slicing an unevaluated
 QuerySet usually returns another unevaluated QuerySet, but Django will
 execute the database query if you use the “step” parameter of slice
 syntax, and will return a list. Slicing a QuerySet that has been evaluated
 (partially or fully) also returns a list.

 By the way, there is also no reference in the documentation(or at least I
 could not find it) to the public method `QuerySet.can_filter`.

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

Re: [Django] #22498: Oracle test failure in migrations: identifier is too long

2014-04-24 Thread Django

#22498: Oracle test failure in migrations: identifier is too long
-+--
 Reporter:  timo |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by timo):

 The offending query is `ALTER TABLE "TEST_RFK_RIDER" ADD CONSTRAINT
 pony_id_refs_id_3e34515040abc59a FOREIGN KEY ("PONY_ID") REFERENCES
 "TEST_RFK_PONY" ("ID") DEFERRABLE INITIALLY DEFERRED` as
 `len('pony_id_refs_id_3e34515040abc59a') > 30` (the limit on Oracle). Shai
 said he will look at it later.

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

Re: [Django] #22499: Oracle test failure: admin_views.tests.AdminViewBasicTest.test_proxy_model_content_type_is_used_for_log_entries

2014-04-24 Thread Django

#22499: Oracle test failure:
admin_views.tests.AdminViewBasicTest.test_proxy_model_content_type_is_used_for_log_entries
-+--
 Reporter:  timo |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"d238c5891239784b61e597c625fe1b340a629da1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d238c5891239784b61e597c625fe1b340a629da1"
 Fixed #22499 -- Fixed a typo in an admin_views test that caused failure on
 Oracle.
 }}}

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

Re: [Django] #22499: Oracle test failure: admin_views.tests.AdminViewBasicTest.test_proxy_model_content_type_is_used_for_log_entries

2014-04-24 Thread Django

#22499: Oracle test failure:
admin_views.tests.AdminViewBasicTest.test_proxy_model_content_type_is_used_for_log_entries
-+--
 Reporter:  timo |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham ):

 In [changeset:"bee118a7011bda1b26e885c7258a8d5e04436863"]:
 {{{
 #!CommitTicketReference repository=""
 revision="bee118a7011bda1b26e885c7258a8d5e04436863"
 [1.7.x] Fixed #22499 -- Fixed a typo in an admin_views test that caused
 failure on Oracle.

 Backport of d238c58912 from master
 }}}

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

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

[django/django] bee118: [1.7.x] Fixed #22499 -- Fixed a typo in an admin_v...

2014-04-24 Thread GitHub

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: bee118a7011bda1b26e885c7258a8d5e04436863
  
https://github.com/django/django/commit/bee118a7011bda1b26e885c7258a8d5e04436863
  Author: Tim Graham 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M tests/admin_views/tests.py

  Log Message:
  ---
  [1.7.x] Fixed #22499 -- Fixed a typo in an admin_views test that caused 
failure on Oracle.

Backport of d238c58912 from master


-- 
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/5358f0584490_175bd4bd40101674%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] d238c5: Fixed #22499 -- Fixed a typo in an admin_views tes...

2014-04-24 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d238c5891239784b61e597c625fe1b340a629da1
  
https://github.com/django/django/commit/d238c5891239784b61e597c625fe1b340a629da1
  Author: Tim Graham 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M tests/admin_views/tests.py

  Log Message:
  ---
  Fixed #22499 -- Fixed a typo in an admin_views test that caused failure on 
Oracle.


-- 
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/5358f0477602c_24d2e2bd3c6025e%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22501: The testing client of LiveServerTestCase has the wrong server address

2014-04-24 Thread Django

#22501: The testing client of LiveServerTestCase has the wrong server address
---+--
 Reporter:  daonb  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 The test client is not meant to query the live server. To interact with
 the live server, use Selenium.

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

[django/django] a742cf: [1.6.x] Renamed Transifex project from django-core...

2014-04-24 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: a742cf17113ab85fc94f4865a7506aeaf7766798
  
https://github.com/django/django/commit/a742cf17113ab85fc94f4865a7506aeaf7766798
  Author: Claude Paroz 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M .tx/config
M docs/internals/contributing/localizing.txt
M scripts/manage_translations.py

  Log Message:
  ---
  [1.6.x] Renamed Transifex project from django-core to django

See also 
http://blog.transifex.com/post/83622601443/new-teams-management-transifex
Backport of 7c24027ba from master.


-- 
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/5358df0165538_2909bc7d3431526%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] 1a3cde: [1.7.x] Renamed Transifex project from django-core...

2014-04-24 Thread GitHub

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 1a3cde5f9fc11ac34251bc44e9f1a82c4ffb4dc8
  
https://github.com/django/django/commit/1a3cde5f9fc11ac34251bc44e9f1a82c4ffb4dc8
  Author: Claude Paroz 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M .tx/config
M docs/internals/contributing/localizing.txt
M scripts/manage_translations.py

  Log Message:
  ---
  [1.7.x] Renamed Transifex project from django-core to django

See also 
http://blog.transifex.com/post/83622601443/new-teams-management-transifex
Backport of 7c24027ba from master.


-- 
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/5358ded1addc1_2bdff8bd44381ee%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] 7c2402: Renamed Transifex project from django-core to djan...

2014-04-24 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 7c24027bad25ebe4bd929bf622eb500446f12b7e
  
https://github.com/django/django/commit/7c24027bad25ebe4bd929bf622eb500446f12b7e
  Author: Claude Paroz 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M .tx/config
M docs/internals/contributing/localizing.txt
M scripts/manage_translations.py

  Log Message:
  ---
  Renamed Transifex project from django-core to django

See also 
http://blog.transifex.com/post/83622601443/new-teams-management-transifex


-- 
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/5358de97da9d7_17dba73d3446616%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20313: AnonymousUser should follow custom User implementation

2014-04-24 Thread Django

#20313: AnonymousUser should follow custom User implementation
-+-
 Reporter:  thinkingpotato@… |Owner:
 Type:  New feature  |  thinkingpotato
Component:  contrib.auth |   Status:  assigned
 Severity:  Normal   |  Version:
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julen):

 * cc: julenx@… (added)


Comment:

 We basically have the same issue but would need to have a different
 solution, since we're using a special user under a reserved username which
 is always considered to be anonymous.

 Perhaps an `ANONYMOUS_USER` attribute in the `AUTH_USER_MODEL` model could
 define what an anonymous user is: a string that matches a value for
 `USERNAME_FIELD`, a specific instance of a class etc.

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

Re: [Django] #22485: makemigrations fails with dependencies to unmigrated apps

2014-04-24 Thread Django

#22485: makemigrations fails with dependencies to unmigrated apps
-+-
 Reporter:  apollo13 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations,  | Triage Stage:  Accepted
  unmigrated, makemigrations |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by dyjo):

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

Re: [Django] #22502: Datetime fields break empty form validation on first attempt (but not second)

2014-04-24 Thread Django

#22502: Datetime fields break empty form validation on first attempt (but not
second)
--+--
 Reporter:  melinath  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.7-beta-2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by melinath):

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


Comment:

 Re-tested, and this '''is''' present even with django-floppyforms
 disabled. So I'm re-opening. Sorry for the confusion.

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

Re: [Django] #22502: Datetime fields break empty form validation on first attempt (but not second)

2014-04-24 Thread Django

#22502: Datetime fields break empty form validation on first attempt (but not
second)
--+--
 Reporter:  melinath  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Forms |  Version:  1.7-beta-2
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by melinath):

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


Comment:

 ... nope, this is a floppyforms bug. :-p Apologies for the extraneous bug.
 Closing now.

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

Re: [Django] #22502: Datetime fields break empty form validation on first attempt (but not second)

2014-04-24 Thread Django

Comment (by melinath):

Nope, this is definitely a django bug. The problem is that the hidden
widget used to keep track of the initial value preserves the microsecond
information, while the datetime widget discards it. Solution to this bug
should then be to either display the microseconds (see also #12139?) or
(what I'd prefer) perform the same conversion on the data for the hidden
input as for the displayed input.

Note that there is a race condition: it is possible (though unlikely) for
the displayed input and hidden input to be different seconds, as well,
since ```BoundField.value()``` is called twice and the results not cached.

Regarding the first vs. second page render: On the second page render,
since the form is now bound, ```BoundField.value()``` returns the
submitted data for the hidden initial value (as well as the displayed
value) instead of the old initial value. Which seems a bit odd, since it
means that data changes on any field with show_hidden_initial will first
cause validation errors and then (on resubmit) simply be ignored. (That
being said, I don't know that there would be a better way to handle this
kind of data.)

(P.S. this bug is maybe related to #12139?)

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

Re: [Django] #22502: Datetime fields break empty form validation on first attempt (but not second)

2014-04-24 Thread Django

#22502: Datetime fields break empty form validation on first attempt (but not
second)
--+--
 Reporter:  melinath  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.7-beta-2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by melinath):

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


Comment:

 I am also using floppyforms, so there's a chance this is a bug in their
 code rather than django. Investigating further.

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

[Django] #22502: Datetime fields break empty form validation on first attempt (but not second)

2014-04-24 Thread Django

#22502: Datetime fields break empty form validation on first attempt (but not
second)
+
 Reporter:  melinath|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.7-beta-2
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 It turns out that if you have a form with ```empty_permitted=True``` (for
 example, an extra form in a formset) and that form has a datetime field
 defaulting to ```(timezone.)now```, the form will fail validation the
 first time you save *even if you touch nothing* – but it will succeed if
 you immediately save again.

 The reason for this seems to lie in the way that initial values for
 datetime fields with defaults are calculated. Specifically, for some
 reason, on first page load, the hidden "initial" field will include
 microseconds - but the displayed datetime field will not. Example:

 {{{
 
 
 }}}

 This means that the field (and thus the form) is marked as "changed".
 However, when the page is re-rendered (with validation errors) the initial
 field's microseconds vanish. Example:

 {{{
 
 
 }}}

 So the form validates just fine on the second go-round.

 I'm technically using the latest code on the 1.7.X branch, not 1.7-beta-2.

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

[Django] #22501: The testing client of LiveServerTestCase has the wrong server address

2014-04-24 Thread Django

#22501: The testing client of LiveServerTestCase has the wrong server address
---+
 Reporter:  daonb  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When executing a test using `self.client` the view's `request` has
 'testserver' as the `SERVER_NAME` and '80' as the `SERVER_PORT` regardless
 of the actual address used by the live server.

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

[django/django] 5cd642: [1.7.x] Prevented a crash in the cursor wrappers o...

2014-04-24 Thread GitHub

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 5cd64296205e1b5cc4fc1f7e02e22d62795bb604
  
https://github.com/django/django/commit/5cd64296205e1b5cc4fc1f7e02e22d62795bb604
  Author: Aymeric Augustin 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M django/db/backends/utils.py

  Log Message:
  ---
  [1.7.x] Prevented a crash in the cursor wrappers on Oracle.

Fixed #22483 (again).

Backport of 0f85103e from master


  Commit: 9bbb43dd1ad0d570d059f18a20db2605c76c8a1e
  
https://github.com/django/django/commit/9bbb43dd1ad0d570d059f18a20db2605c76c8a1e
  Author: Aymeric Augustin 
  Date:   2014-04-24 (Thu, 24 Apr 2014)

  Changed paths:
M django/db/backends/__init__.py

  Log Message:
  ---
  [1.7.x] Ignored repeated calls to connection.close().

Backport of d4cc59ef from master


Compare: https://github.com/django/django/compare/e32e359d6ab4...9bbb43dd1ad0

-- 
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/5358b28fe4786_2892e89d38131546%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22483: Oracle test failures due to InterfaceError

2014-04-24 Thread Django

#22483: Oracle test failures due to InterfaceError
-+-
 Reporter:  timo |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 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 Aymeric Augustin ):

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


Comment:

 In [changeset:"5cd64296205e1b5cc4fc1f7e02e22d62795bb604"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5cd64296205e1b5cc4fc1f7e02e22d62795bb604"
 [1.7.x] Prevented a crash in the cursor wrappers on Oracle.

 Fixed #22483 (again).

 Backport of 0f85103e from master
 }}}

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

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

Re: [Django] #22483: Oracle test failures due to InterfaceError

2014-04-24 Thread Django

#22483: Oracle test failures due to InterfaceError
-+-
 Reporter:  timo |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |  1.7-beta-1
 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 aaugustin):

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


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

Re: [Django] #22500: Django1.7, mysql backend makemigrations not work

2014-04-24 Thread Django

#22500: Django1.7, mysql backend makemigrations not work
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.7-beta-2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 What are you doing?

 What result are you getting?

 What result are you expecting?

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

53 matches

Mail list logo