Re: [Django] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
-+-
   Reporter: |  Owner:  nobody
  alexandrul | Status:  reopened
   Type:  New|  Component:  Documentation
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  1
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by alexandrul):

 What should be done next? The supplied patch works fine here. It must be
 validated by someone else?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16483: manage.py shell does not work with the latest IPython release (0.11.rc2)

[Django]

#16483: manage.py shell does not work with the latest IPython release (0.11.rc2)
-+-
   Reporter:  croach |  Owner:  croach
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Management
Version:  SVN|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by minrk):

 Does the previous code actually not work, or is this purely prompted by
 the IPython docs?

 A few points:

 1. You don't have to handle any fallbacks, there have been no releases of
 IPython without IPShell, and both `TerminalInteractiveShell` and embed()
 are introduced in 0.11, to be released this week. 0.11 is a major
 reorganization of IPython, so some imports were in flux early on, but
 these have not changed in a year.
 2. embed() is for invoking a special `InteractiveShell` that uses the
 calling scope to initialize the user namespace (i.e. `self` will be
 defined if you use it as proposed here). Is that what you want? embed() is
 typically used in debugging, as it lets you have a full IPython shell at
 breakpoints.
 3. `manage.py shell` appears to work just fine with IPython master today
 (to be 0.11 final very soon) and django release 1.3, but I'm not familiar
 with how IPython is supposed to be different than usual when invoked by
 django, so maybe that's not accurate.

 The only change that should probably be made is that
 `TerminalInteractiveShell` should be imported from
 `IPython.frontend.terminal.interactiveshell` (where it's always been
 defined), not `IPython.frontend.terminal.embed`, which just happens to
 also import 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

[Django]

#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
   Reporter:  favo   |  Owner:  nobody
     | Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by kmike):

 * cc: kmike84@… (added)
 * ui_ux:   => 0
 * easy:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4102: Allow UPDATE of only specific fields in model.save()

[Django]

#4102: Allow UPDATE of only specific fields in model.save()
-+-
   Reporter:  Collin |  Owner:  cgrady
  Grady    | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  update fields sql
 Resolution: |  row table modified
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by kmike):

 * cc: kmike84@… (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
   Reporter:  Manfred|  Owner:  jgelens
  Wassmann | Status:  assigned
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  dceu2011
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by tmitchell):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
   Reporter:  Manfred|  Owner:  jgelens
  Wassmann | Status:  assigned
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  dceu2011
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by tmitchell):

 * needs_better_patch:  0 => 1


Comment:

 Looks like something went awry with the last patch posted, the tests and
 some other things disappeared.  Here's the combined patch, with a test for
 the self-referential Fk described above and an edit to the docs for
 readability.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4186: [boulder-oracle] Error using "SELECT DISTINCT" with TextFields

[Django]

#4186: [boulder-oracle] Error using "SELECT DISTINCT" with TextFields
-+-
   Reporter:  khoobks@…  |Owner:  nobody
   Type: |   Status:  closed
  Milestone: |Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution:  wontfix| Severity:
   Triage Stage:  Accepted   | Keywords:  oracle distinct NCLOB
Needs documentation:  0  |  TextField
Patch needs improvement:  0  |Has patch:  0
 |  Needs tests:  0
-+-

Comment (by ramiro):

 In [16546]:
 {{{
 #!CommitTicketReference repository="" revision="16546"
 Fixed #16480 -- Modified test added in r16522 so it doesn't use a query
 not supported under Oracle (`GROUP BY` a NCLOB field). Thanks Aymeric for
 the report. Refs #4186
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16480: DeferRegressionTest.test_basic fails under Oracle

[Django]

#16480: DeferRegressionTest.test_basic fails under Oracle
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution:  fixed  |   Severity:  Release blocker
   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 ramiro):

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


Comment:

 In [16546]:
 {{{
 #!CommitTicketReference repository="" revision="16546"
 Fixed #16480 -- Modified test added in r16522 so it doesn't use a query
 not supported under Oracle (`GROUP BY` a NCLOB field). Thanks Aymeric for
 the report. Refs #4186
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16546 - django/trunk/tests/regressiontests/defer_regress

[noreply]

Author: ramiro
Date: 2011-07-17 15:22:39 -0700 (Sun, 17 Jul 2011)
New Revision: 16546

Modified:
   django/trunk/tests/regressiontests/defer_regress/models.py
   django/trunk/tests/regressiontests/defer_regress/tests.py
Log:
Fixed #16480 -- Modified test added in r16522 so it doesn't use a query not 
supported under Oracle (`GROUP BY` a NCLOB field). Thanks Aymeric for the 
report. Refs #4186

Modified: django/trunk/tests/regressiontests/defer_regress/models.py
===
--- django/trunk/tests/regressiontests/defer_regress/models.py  2011-07-17 
14:17:26 UTC (rev 16545)
+++ django/trunk/tests/regressiontests/defer_regress/models.py  2011-07-17 
22:22:39 UTC (rev 16546)
@@ -36,3 +36,13 @@
 class Proxy(Item):
 class Meta:
 proxy = True
+
+class SimpleItem(models.Model):
+name = models.CharField(max_length=15)
+value = models.IntegerField()
+
+def __unicode__(self):
+return self.name
+
+class Feature(models.Model):
+item = models.ForeignKey(SimpleItem)

Modified: django/trunk/tests/regressiontests/defer_regress/tests.py
===
--- django/trunk/tests/regressiontests/defer_regress/tests.py   2011-07-17 
14:17:26 UTC (rev 16545)
+++ django/trunk/tests/regressiontests/defer_regress/tests.py   2011-07-17 
22:22:39 UTC (rev 16546)
@@ -6,7 +6,8 @@
 from django.db.models.loading import cache
 from django.test import TestCase
 
-from models import ResolveThis, Item, RelatedItem, Child, Leaf, Proxy
+from models import (ResolveThis, Item, RelatedItem, Child, Leaf, Proxy,
+SimpleItem, Feature)
 
 
 class DeferRegressionTest(TestCase):
@@ -108,11 +109,13 @@
 self.assertEqual(
 klasses, [
 Child,
+Feature,
 Item,
 Leaf,
 Proxy,
 RelatedItem,
 ResolveThis,
+SimpleItem,
 ]
 )
 
@@ -128,6 +131,7 @@
 klasses, [
 "Child",
 "Child_Deferred_value",
+"Feature",
 "Item",
 "Item_Deferred_name",
 "Item_Deferred_name_other_value_text",
@@ -144,12 +148,13 @@
 "RelatedItem_Deferred_",
 "RelatedItem_Deferred_item_id",
 "ResolveThis",
+"SimpleItem",
 ]
 )
 
 # Regression for #16409 - make sure defer() and only() work with 
annotate()
-
self.assertIsInstance(list(Item.objects.annotate(Count('relateditem')).defer('name')),
 list)
-
self.assertIsInstance(list(Item.objects.annotate(Count('relateditem')).only('name')),
 list)
+
self.assertIsInstance(list(SimpleItem.objects.annotate(Count('feature')).defer('name')),
 list)
+
self.assertIsInstance(list(SimpleItem.objects.annotate(Count('feature')).only('name')),
 list)
 
 def test_only_and_defer_usage_on_proxy_models(self):
 # Regression for #15790 - only() broken for proxy models

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
   Reporter: |  Owner:  charettes
  marcin.tustin@…| Status:  assigned
   Type:  Bug|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  forms formsets
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by charettes):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
   Reporter: |  Owner:  nobody
  marcin.tustin@…| Status:  new
   Type:  Bug|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  forms formsets
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by charettes):

 Added a patch with fix and tests.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16483: manage.py shell does not work with the latest IPython release (0.11.rc2)

[Django]

#16483: manage.py shell does not work with the latest IPython release (0.11.rc2)
-+-
   Reporter:  croach |  Owner:  croach
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Management
Version:  SVN|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by croach):

 I've only replaced the portion that is responsible for IPython v0.11. The
 other fallbacks have been left untouched. So, this patch should only
 really fix the 0.11 portion of the code to work with the latest release of
 0.11. Earlier stable releases should still function properly, but earlier
 0.11 release candidates, alphas, etc. might not. This seems reasonable
 that Django would support stable versions and the latest release
 candidate. Also, since this is a release candidate and not an earlier
 alpha/beta, things should be slightly more settled (hopefully) as I
 believe the IPython devs are nearing a stable release of 0.11 very soon.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
   Reporter: |  Owner:  nobody
  marcin.tustin@…| Status:  new
   Type:  Bug|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  forms formsets
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16454: sequence for AUTH_PERMISSION.ID

[Django]

#16454: sequence for AUTH_PERMISSION.ID
-+-
   Reporter: |  Owner:  nobody
  alexei.vlassov@…   | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Release blocker
 Resolution:  needsinfo  |   Keywords:  oracle
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I couldn't reproduce the problem with the following procedure:

 - `django-admin.py startproject test16454`
 - `vi settings.py`

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.oracle',
 'NAME': '',
 'USER': 'django',
 'PASSWORD': 'django',
 }
 }
 DEFAULT_TABLESPACE = 'test16454'
 DEFAULT_INDEX_TABLESPACE = 'test16454'
 }}}

 - `sqlplus`

 {{{
 create tablespace test16454 datafile 'test16454.dbf' size 20M;
 }}}

 - `./manage.py syncdb`

 {{{
 Creating tables ...
 Creating table auth_permission
 Creating table auth_group_permissions
 Creating table auth_group
 Creating table auth_user_user_permissions
 Creating table auth_user_groups
 Creating table auth_user
 Creating table django_content_type
 Creating table django_session
 Creating table django_site

 You just installed Django's auth system, which means you don't have any
 superusers defined.
 Would you like to create one now? (yes/no): yes
 Username (leave blank to use 'aaugustin'): [[[ redacted ]]]
 E-mail address: [[[ redacted ]]]
 Password:
 Password (again):
 Superuser created successfully.
 Installing custom SQL ...
 Installing indexes ...
 No fixtures found.
 }}}

 Oracle Database 10g Express Edition Release 10.2.0.1.0

 Since  the original report doesn't contain any information about the
 context, there isn't much more I can do.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16478: Don't hardcode the location of Oracle's datafiles for the test tablespaces

[Django]

#16478: Don't hardcode the location of Oracle's datafiles for the test 
tablespaces
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  oracle
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 Here is a new patch that documents the undocumented Oracle-specific
 settings. I'm now using this, and I'm creating and dropping the user and
 the tablespaces with a separate SQL script.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16482: 16545 security doc grammar fix introduced a typo

[Django]

#16482: 16545 security doc grammar fix introduced a typo
-+-
   Reporter:  charettes  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16483: manage.py shell does not work with the latest IPython release (0.11.rc2)

[Django]

#16483: manage.py shell does not work with the latest IPython release (0.11.rc2)
-+-
   Reporter:  croach |  Owner:  croach
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Management
Version:  SVN|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 Will this patch work with all versions of IPython? To put it differently,
 is it guaranteed that all versions of IPython provide either `embed` or
 `IPShell`?

 Otherwise, we must try `embed`, fall back to `TerminalInteractiveShell`,
 and fall back again to `IPShell`.

 See also r14895. Apparently, the IPython devs like changing their main
 public API every 6 months :(

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16483: manage.py shell does not work with the latest IPython release (0.11.rc2)

[Django]

#16483: manage.py shell does not work with the latest IPython release (0.11.rc2)
+
 Reporter:  croach  |  Owner:  croach
 Type:  Bug | Status:  new
Milestone:  |  Component:  Core (Management commands)
  Version:  SVN |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  1   |  Easy pickings:  0
UI/UX:  0   |
+
 The latest release candidate for the IPython application has changed the
 way in which an IPython instance is embedded. According to the latest
 IPython documentation (http://bit.ly/q1yj0O) an IPython instance can be
 embedded as follows:

 {{{
 from IPython import embed
 embed()
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
   Reporter: |  Owner:  nobody
  marcin.tustin@…| Status:  new
   Type:  Bug|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  forms formsets
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  1
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by charettes):

 * needs_tests:  0 => 1


Comment:

 Looks like a bug to me, can someone confirm? If it's accepted it'll need
 tests.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16482: 16545 security doc grammar fix introduced a typo

[Django]

#16482: 16545 security doc grammar fix introduced a typo
--+---
 Reporter:  charettes |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Documentation
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  1
UI/UX:  0 |
--+---
 
https://github.com/django/django/commit/322eb3ee6d71e5c4f0f07b327094ace625e7d8c6
 "executred"

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11665: django.test.TestCase should flush constraints

[Django]

#11665: django.test.TestCase should flush constraints
+---
   Reporter:  Glenn |  Owner:
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  SVN   |   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 |
+---

Comment (by jsdalton):

 Attached is an initial patch which encapsulates a slightly modified
 approach to the one outlined in my previous comment and originally
 proposed on the dev list.

 In short, Simon Riggs pointed out in that discussion
 (https://groups.google.com/d/topic/django-
 developers/J_5SuL0MoQU/discussion) that my conception of how transactions
 work was too naive and my proposed solution (to set constraint checks
 immediately at the start) did not in fact accurately reflect how things
 work in production.

 Fortunately, the solution wasn't too hard. Emulating production behavior
 better is a simple matter of adjusting the way we monkey patch the
 `transaction` functions in the set up of TestCase. Rather than simply
 stubbing those out, I added the constraint checking feature from #3615 in
 its place. So even though the main transaction functions don't *do* what
 they do in production (i.e. actually commit or rollback the function),
 they now perform the constraint check they normally would at that point
 and raise the appropriate IntegrityError when they do.).

 The patch also includes a test which demonstrates that an IntegrityError
 should be raised during a TestCase test if bad data is entered.

 The patch is not complete for several reasons:

 * Haven't addressed any of the errors that this raises in the rest of the
 suite yet. I have some solutions for many but I'd rather focus on getting
 a solution to the immediate issue down.
 * I have one concern about the implementation of check_constraints() on
 postgresql (and Oracle perhaps). If the autocommit feature is on, then
 does it make sense to revert to deferred? I think those statements are all
 irrelevant if that mode is on, so I think the answer is probably no.
 * I wonder if it makes sense to make use of a savepoint at the start of
 tests (and release it at the end), and then rollback to that savepoint if
 for any reason a constraint check fails? That would allow tests to
 continue even if a (planned) IntegrityError was hit. This seems like a
 rather obscure feature, but there is a theoretical possibility of tests
 that previously worked (when we never checked constraints) which might
 fail now, since once you hit an IntegrityError the test is for all intents
 and purposes over.

 Note that this patch includes the entire latest patch from #3615, because
 it depends on that patch in order to work. Here's a diff between this
 patch and that patch which highlights the focus of this patch
 (http://paste.pocoo.org/show/440770/).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16545 - django/trunk/docs/topics

[noreply]

Author: lukeplant
Date: 2011-07-17 07:17:26 -0700 (Sun, 17 Jul 2011)
New Revision: 16545

Modified:
   django/trunk/docs/topics/security.txt
Log:
Grammar fixes and content tweaks to XSS section of security docs.

Modified: django/trunk/docs/topics/security.txt
===
--- django/trunk/docs/topics/security.txt   2011-07-14 19:40:30 UTC (rev 
16544)
+++ django/trunk/docs/topics/security.txt   2011-07-17 14:17:26 UTC (rev 
16545)
@@ -12,12 +12,13 @@
 
 .. highlightlang:: html+django
 
-XSS attacks allow a user to inject client side scripts into the
-browsers of other users. This is usually achieved by storing the malicious
-scripts to the database where it will be retrieved and displayed to other users
-or to get users to click a link containing variables containing scripts that
-will be rendered by the user's browser. However, XSS attacks can originate
-from any untrusted source of data such as cookies or web services.
+XSS attacks allow a user to inject client side scripts into the browsers of
+other users. This is usually achieved by storing the malicious scripts in the
+database where it will be retrieved and displayed to other users, or by getting
+users to click a link which will cause the attacker's javascript to be 
executred
+by the user's browser. However, XSS attacks can originate from any untrusted
+source of data, such as cookies or web services, whenever the data is not
+sufficiently sanitized before including in a page.
 
 Using Django templates protects you against the majority of XSS attacks.
 However, it is important to understand what protections it provides
@@ -44,8 +45,8 @@
 than HTML, there may be entirely separate characters and words which require
 escaping.
 
-You should also be very careful when storing HTML to the database especially
-when that HTML will be retrieved and displayed.
+You should also be very careful when storing HTML in the database, especially
+when that HTML is retrieved and displayed.
 
 Cross site request forgery (CSRF) protection
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16481: DBCacheTests.test_cull fails under Oracle

[Django]

#16481: DBCacheTests.test_cull fails under Oracle
---+---
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Milestone: |Component:  Core (Cache system)
  Version:  1.3| 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
---+---
 {{{
 $ python runtests.py --settings=test_settings.oracle cache
 Creating test database for alias 'default'...
 Creating test user...
 Creating test database for alias 'other'...
 Creating test user...
 
...E...
 ==
 ERROR: test_cull (regressiontests.cache.tests.DBCacheTests)
 --
 Traceback (most recent call last):
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/tests/regressiontests/cache/tests.py",
 line 750, in test_cull
 self.perform_cull_test(50, 29)
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/tests/regressiontests/cache/tests.py",
 line 417, in perform_cull_test
 self.cache.set('cull%d' % i, 'value', 1000)
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/core/cache/backends/db.py",
 line 65, in set
 self._base_set('set', key, value, timeout)
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/core/cache/backends/db.py",
 line 84, in _base_set
 self._cull(db, cursor, now)
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/core/cache/backends/db.py",
 line 138, in _cull
 cursor.execute("SELECT cache_key FROM %s ORDER BY cache_key LIMIT 1
 OFFSET %%s" % table, [num / self._cull_frequency])
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/db/backends/oracle/base.py",
 line 638, in execute
 return self.cursor.execute(query, self._param_generator(params))
 DatabaseError: ORA-00933: SQL command not properly ended


 --
 Ran 179 tests in 26.809s

 FAILED (errors=1, skipped=32)
 Destroying test database for alias 'default'...
 Destroying test user...
 Destroying test database tables...
 Destroying test database for alias 'other'...
 Destroying test user...
 Destroying test database tables...
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16480: DeferRegressionTest.test_basic fails under Oracle

[Django]

#16480: DeferRegressionTest.test_basic fails under Oracle
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Milestone:   |Component:  Database
  Version:  1.3  |  layer (models, ORM)
 Keywords:   | Severity:  Release
Has patch:  0|  blocker
  Needs tests:  0| Triage Stage:
Easy pickings:  0|  Unreviewed
 |  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
 {{{
 $ python runtests.py --settings=test_settings.oracle defer_regress
 Creating test database for alias 'default'...
 Creating test user...
 Creating test database for alias 'other'...
 Creating test user...
 E..
 ==
 ERROR: test_basic
 (regressiontests.defer_regress.tests.DeferRegressionTest)
 --
 Traceback (most recent call last):
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/tests/regressiontests/defer_regress/tests.py",
 line 151, in test_basic
 
self.assertIsInstance(list(Item.objects.annotate(Count('relateditem')).defer('name')),
 list)
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/db/models/query.py",
 line 81, in __len__
 self._result_cache.extend(self._iter)
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/db/models/query.py",
 line 270, in iterator
 for row in compiler.results_iter():
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/db/models/sql/compiler.py",
 line 699, in results_iter
 for rows in self.execute_sql(MULTI):
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/db/models/sql/compiler.py",
 line 754, in execute_sql
 cursor.execute(sql, params)
   File
 
"/var/lib/jenkins/jobs/Django/workspace/settings/oracle/django/db/backends/oracle/base.py",
 line 638, in execute
 return self.cursor.execute(query, self._param_generator(params))
 DatabaseError: ORA-00932: inconsistent datatypes: expected - got NCLOB


 --
 Ran 3 tests in 0.567s

 FAILED (errors=1)
 Destroying test database for alias 'default'...
 Destroying test user...
 Destroying test database tables...
 Destroying test database for alias 'other'...
 Destroying test user...
 Destroying test database tables...
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16478: Don't hardcode the location of Oracle's datafiles for the test tablespaces

[Django]

#16478: Don't hardcode the location of Oracle's datafiles for the test 
tablespaces
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  oracle
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 Upon further investigation, there are undocumented `TEST_CREATE` and
 `TEST_USER_CREATE` boolean parameters.

 The best solution may be to set `TEST_CREATE = False` and create the
 tablespace with whatever parameters I want.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13539: The delete confirmation page does not check for object-level permissions when building the related list

[Django]

#13539: The delete confirmation page does not check for object-level permissions
when building the related list
-+-
   Reporter: |  Owner:  cyrus
  delinhabit | Status:  assigned
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.2-beta   |   Keywords:  delete object-level
 Resolution: |  permissions
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by cyrus):

 While investigating the failing test, I came across an interesting thing:
 if you have a backend that does not support object-level permissions (like
 the default ModelBackend) a user will not have permissions for an object
 even if that user have permissions for the model itself. I think this is
 weird, because philosophically if I have delete permissions for MyModel I
 should also have delete permissions for an object of MyModel if my
 authentication back-end does not enforce object-level permissions.

 Attached you can find a patch for this issue
 ([attachment:r16544_13539.diff]). Note that this patch make the following
 tests to fail:
 *
 django.contrib.auth.tests.auth_backends.BackendTest.test_has_no_object_perm
 *
 django.contrib.auth.tests.auth_backends.NoInActiveUserBackendTest.test_has_perm
 *
 django.contrib.auth.tests.auth_backends.RowlevelBackendTest.test_has_perm

 I think the reason for this is that those tests were written with this
 assumption in mind. I can fix the failing tests and create additional
 tests to regress this issue, but I want to discuss first. Any thoughts?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12610: Fixture loading is interfered by signal handlers

[Django]

#12610: Fixture loading is interfered by signal handlers
-+-
   Reporter:  jtiai  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by vanschelven):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 This appears to be closely related to #8399

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+-
   Reporter: |  Owner:  nobody
  marcin.tustin@…| Status:  new
   Type:  Bug|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  forms formsets
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

 * needs_better_patch:   => 0
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16479: Forms generated from formsets use ErrorList instead of supplied error_class

[Django]

#16479: Forms generated from formsets use ErrorList instead of supplied 
error_class
-+
 Reporter:  marcin.tustin@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Forms
  Version:  1.3  |   Severity:  Normal
 Keywords:  forms formsets   |   Triage Stage:  Unreviewed
Has patch:  1|  Easy pickings:  1
UI/UX:  0|
-+
 Using Django 1.3, forms generated from formsets use ErrorList instead of
 supplied error_class.

 Accordingly, even though a formset is instantiated:

 directors_formset = DirectorsFormset(prefix='directors',
  data=request.POST,
 error_class=SideError)

 Forms generated from it use the default ErrorList ul style of error
 rendering.

 The fix is in the first line of FormSet._construct_form, which currently
 reads:
 defaults = {'auto_id': self.auto_id, 'prefix': self.add_prefix(i)}
 
(https://code.djangoproject.com/browser/django/trunk/django/forms/formsets.py#L114)

 This should be changed to:
 defaults = {'auto_id': self.auto_id, 'prefix': self.add_prefix(i),
 'error_class': self.error_class}
 Which passes the error_class down to every form instantiated.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12464: Empty PATH_INFO causes blank SCRIPT_NAME

[Django]

#12464: Empty PATH_INFO causes blank SCRIPT_NAME
-+---
   Reporter:  chrisw |  Owner:  wogan
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  SVN|   Severity:  Normal
 Resolution:  needsinfo  |   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 jezdez):

 * status:  assigned => closed
 * ui_ux:   => 0
 * resolution:   => needsinfo


Comment:

 I honestly couldn't follow this ticket's discussion since it seemed to
 have diverged into a Apache support thread. Please provide more
 information of that Django does wrong here.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16478: Don't hardcode the location of Oracle's datafiles for the test tablespaces

[Django]

#16478: Don't hardcode the location of Oracle's datafiles for the test 
tablespaces
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  oracle
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 NB: during the test suite, each tablespace takes 160MB (see attached
 screenshot). This is a good reason to move it to RAM.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16478: Don't hardcode the location of Oracle's datafiles for the test tablespaces

[Django]

#16478: Don't hardcode the location of Oracle's datafiles for the test 
tablespaces
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |Component:  Testing
Milestone:   |  framework
  Version:  1.3  | Severity:  Normal
 Keywords:  oracle   | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
 '''Use case:''' I want to move Oracle's datafiles to a RAM disk (tmpfs) to
 speed up the execution of Django's test suite.

 '''Problem:''' `django.db.backends.oracle.creation` currently uses this
 SQL: `CREATE TABLESPACE %(tblspace)s DATAFILE '%(tblspace)s.dbf' ...`

 It's allright to provide a datafile name, because we can't assume all
 users of Django are using Oracle-managed files. However, since we provide
 a relative path, the file will always be created in Oracle's `dbs`
 directory. The `DB_CREATE_FILE_DEST` parameter is ignored when a datafile
 name is provided.

 See
 
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/clauses004.htm#i1030551
 (if you speak Oraclese).

 '''Proposed solution:''' add an optional setting to control the location
 of the datafile during the tests. If the setting is not provided, default
 to `TEST_TBLSPACE + '.dbf'` for backwards compatibility.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13539: The delete confirmation page does not check for object-level permissions when building the related list

[Django]

#13539: The delete confirmation page does not check for object-level permissions
when building the related list
-+-
   Reporter: |  Owner:  cyrus
  delinhabit | Status:  assigned
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.2-beta   |   Keywords:  delete object-level
 Resolution: |  permissions
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by cyrus):

 * owner:  nobody => cyrus
 * status:  new => assigned
 * ui_ux:   => 0
 * easy:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11383: Admin action 'Delete selected' check only global model delete permission

[Django]

#11383: Admin action 'Delete selected' check only global model delete permission
-+-
   Reporter:  krejcik@…  |  Owner:  cyrus
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  contrib.admin
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  delete permission
   Triage Stage:  Accepted   |  admin
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by cyrus):

 * owner:  nobody => cyrus
 * status:  new => assigned
 * ui_ux:   => 0
 * easy:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.