Re: [Django] #6961: loaddata fails if models directory instead of models.py

[Django]

#6961: loaddata fails if models directory instead of models.py
+---
  Reporter:  pmd| Owner:  nobody  
Status:  closed | Milestone:  
 Component:  django-admin.py|   Version:  SVN 
Resolution:  fixed  |  Keywords:  loaddata
 Stage:  Ready for checkin  | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 Requiring models for various things is a seperate issue, closing this as
 the bug here was fixed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #6961: loaddata fails if models directory instead of models.py

[Django]

#6961: loaddata fails if models directory instead of models.py
+---
  Reporter:  pmd| Owner:  nobody  
Status:  reopened   | Milestone:  
 Component:  django-admin.py|   Version:  SVN 
Resolution: |  Keywords:  loaddata
 Stage:  Ready for checkin  | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by xcc...@gmail.com):

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

Comment:

 Bump on stephaner's comment.  Why are models needed at all?  Consider the
 case where you have an app for doing various things for your site.  There
 may not be any models, but there may be an initial_data fixture to add in
 a default user or Site information.

-- 
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-upda...@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] #13976: Admin view with relations (ForeignKey or ManyToMany) does not limit number of entries in document

[Django]

#13976: Admin view with relations (ForeignKey or ManyToMany) does not limit 
number
of entries in document
--+-
  Reporter:  yn...@opera.com  | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Uncategorized|   Version:  1.1   
Resolution:  invalid  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by hcarvalhoalves):

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

Comment:

 Part of your problem is solved by the use of the ''raw_id_fields''
 attribute in the Admin class, which avoids pre-loading related data under
 the edit forms. Refer to the documentation:

 http://docs.djangoproject.com/en/1.2/ref/contrib/admin/#raw-id-fields

 The other part, involves overriding the delete confirmation template to
 not list related objects, thus avoid hitting the database. To change this,
 customize the template existent at
 django/contrib/admin/templates/delete_confirmation.html under you project
 templates directory. Again, refer to the documentation to learn how to
 override the admin templates:

 http://docs.djangoproject.com/en/dev/ref/contrib/admin/#overriding-admin-
 templates

 This is a common question, but couldn't find a dupe, so I'm closing as
 invalid and keeping the instructions to hopefully help someone else coming
 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 post to this group, send email to django-upda...@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] #13844: Errors when using character fields for aggregation

[Django]

#13844: Errors when using character fields for aggregation
---+
  Reporter:  zeg...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by chronos):

 * cc: philipe...@gmail.com (added)
  * has_patch:  0 => 1

Comment:

 I'm the guy at IRC. The proposed fix already works for me. I having
 troubles in get Max from a charfield.

 Given model:
 {{{
 class Link_A(models.Model):
 link = models.CharField(max_length=500)
 short_link = models.CharField(max_length=50)
 }}}

 I get following error when try to get Max of short_link:
 {{{
 In [5]: Link_A.objects.all().aggregate(Max('short_link'))
 ---
 ValueErrorTraceback (most recent call
 last)

 /home/felipe/projects/testproject/ in ()

 /home/felipe/.py/2.6/lib/python2.6/site-
 packages/django/db/models/query.pyc in aggregate(self, *args, **kwargs)
 311 is_summary=True)
 312
 --> 313 return query.get_aggregation(using=self.db)
 314
 315 def count(self):

 /home/felipe/.py/2.6/lib/python2.6/site-
 packages/django/db/models/sql/query.pyc in get_aggregation(self, using)
 371 (alias, self.resolve_aggregate(val, aggregate,
 connection=connections[using]))
 372 for (alias, aggregate), val
 --> 373 in zip(query.aggregate_select.items(), result)
 374 ])
 375

 /home/felipe/.py/2.6/lib/python2.6/site-
 packages/django/db/models/sql/query.pyc in resolve_aggregate(self, value,
 aggregate, connection)
 325 else:
 326 # Return value depends on the type of the field being
 processed.

 --> 327 return self.convert_values(value, aggregate.field,
 connection)
 328
 329 def get_aggregation(self, using):

 /home/felipe/.py/2.6/lib/python2.6/site-
 packages/django/db/models/sql/query.pyc in convert_values(self, value,
 field, connection)
 303 it can be overridden by Query classes for specific
 backends.
 304 """
 --> 305 return connection.ops.convert_values(value, field)
 306
 307 def resolve_aggregate(self, value, aggregate, connection):

 /home/felipe/.py/2.6/lib/python2.6/site-
 packages/django/db/backends/__init__.pyc in convert_values(self, value,
 field)
 443 # No field, or the field isn't known to be a decimal or
 integer

 444 # Default to a float

 --> 445 return float(value)
 446
 447 def check_aggregate_support(self, aggregate_func):

 ValueError: invalid literal for float(): c
 }}}

 and checking queries, I can see that querie are made:
 {{{
 In [6]: connection.queries
 Out[6]:
 [{'sql': 'SELECT MAX("webui_link_a"."short_link") AS "short_link__max"
 FROM "webui_link_a"',
   'time': '0.001'}]
 }}}

 That's is a small fix, but I think that need to check how act with others
 internal types, or default to float only if float(value) don't raise
 nothing and just return value if raise.

-- 
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-upda...@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] #13844: Errors when using character fields for aggregation

[Django]

#13844: Errors when using character fields for aggregation
---+
  Reporter:  zeg...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by SmileyChris):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  => 0
  * summary:  ValueError: by adding custom aggregate  function TRIM =>
  Errors when using character fields for
  aggregation
  * version:  1.1 => 1.2
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

Comment:

 For the life of me I can't understand the logic of the original
 `convert_values` method, but it definitely seems wrong.

 Someone in IRC encountered a problem because of this using the built in
 `Max` aggregation class with a charfield, so it's not just custom
 aggregate classes which are effected 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-upda...@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] #13956: Indefinite args for simpletags and inclusion tags

[Django]

#13956: Indefinite args for simpletags and inclusion tags
--+-
  Reporter:  melinath | Owner:  gregmuellegger
Status:  assigned | Milestone:
 Component:  Template system  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  1|   Needs_tests:  1 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * stage:  Design decision needed => 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-upda...@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] #8851: Please add a default option to list_filter in the admin interface

[Django]

#8851: Please add a default option to list_filter in the admin interface
--+-
  Reporter:  Riskable   | Owner:  
nobody 
Status:  reopened | Milestone:  
   
 Component:  django.contrib.admin |   Version:  SVN 
   
Resolution:   |  Keywords:  
admin, list_filter, default
 Stage:  Accepted | Has_patch:  0   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Changes (by wiz...@roborooter.com):

 * cc: wiz...@roborooter.com (added)

Comment:

 Is this something that just needs committing?

-- 
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-upda...@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] #13971: Excluding a declar ed field in ModelForm in form’s subcl ass

[Django]

#13971: Excluding a declared field in ModelForm in form’s subclass
-+--
  Reporter:  mitar   | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by mitar):

 No, I do not have a solution, I have just a workaround.

 Workaround is (for example for form above) to do:

 {{{
 class MyUserChangeForm(UserChangeForm):
   class Meta(UserChangeForm.Meta):
 fields = ('first_name', 'last_name', 'email')

   def __init__(self, *args, **kwargs):
 super(MyUserChangeForm, self).__init__(*args, **kwargs)
 del self.fields['username'] # This is a declared field we really want
 to be removed
 }}}

-- 
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-upda...@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] #13971: Excluding a declar ed field in ModelForm in form’s subcl ass

[Django]

#13971: Excluding a declared field in ModelForm in form’s subclass
-+--
  Reporter:  mitar   | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jfenwick):

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

Comment:

 mitar are you saying you have a solution? I don't quite understand it. Do
 you have a patch?
 I'm also having this problem.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13977: Indeterministic PicklingError

[Django]

#13977: Indeterministic PicklingError
--+-
  Reporter:  etam | Owner:  nobody
Status:  new  | Milestone:
 Component:  django.contrib.sessions  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by etam):

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

Comment:

 There is similar problem (thanks to Dan Breslau from stackoverflow.com -
 [http://stackoverflow.com/questions/3292383/django-mod-wsgi-picklingerror-
 while-saving-object]):

 {{{
 >>> import cPickle
 >>> class Foo(object):
 ... pass
 ...
 >>> f = Foo()
 >>> s = cPickle.dumps(f)
 >>>
 >>> # Redefine class Foo
 >>> class Foo(object):
 ... pass
 ...
 >>> # Now attempt to pickle the same object that was created with the old
 Foo class
 >>> s = cPickle.dumps(f)
 Traceback (most recent call last):
   File "", line 1, in 
 cPickle.PicklingError: Can't pickle : it's not the
 same object as __main__.Foo
 >>>
 >>> # Create an object with the new Foo class, and try to pickle it (this
 works)
 >>> f2 = Foo()
 >>> s = cPickle.dumps(f2)
 }}}

-- 
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-upda...@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] #13978: Allow inline js/css in forms.Media

[Django]

#13978: Allow inline js/css in forms.Media
---+
 Reporter:  nathforge  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 It's not possible to use the Media class for inline Javascript or CSS
 content, though this is often useful when bootstrapping external scripts.

 Widgets can include inline content in their render method, but
 ModelAdmin's appear to be out of luck.

 I've attached a patch to allow inline content, e.g:

 {{{
 @property
 def media(self):
 return forms.Media(
 js=(forms.Media.Inline('alert("Test")'),),
 css={
 'all': (forms.Media.Inline('body { background: black
 }'),),
 }
 )
 }}}

-- 
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-upda...@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] #8342: The admin wrongly assumes you can't login with your email

[Django]

#8342: The admin wrongly assumes you can't login with your email
---+
  Reporter:  julien| Owner:  nobody
Status:  reopened  | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by bendavis78):

 Honestly, I don't understand why there's any validation on the log-in form
 other than to authenticate the given credentials.  That kind of validation
 should only be done when creating or modifying a user, not when logging
 in.  In fact,  best security practices dictate that the only error message
 you should show when logging in is "the username and/or password is
 incorrect".

-- 
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-upda...@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] #694: [patch] TEMPLATE_DIRS should allow project root relative paths

[Django]

#694: [patch] TEMPLATE_DIRS should allow project root relative paths
--+-
  Reporter:  nirvdrum | Owner:  adrian
Status:  closed   | Milestone:
 Component:  Template system  |   Version:  SVN   
Resolution:  wontfix  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by sorin):

 * cc: sorin (added)
  * version:  => SVN

Comment:

 Please reconsider this issue, it is #1 having more than 100 votes on
 http://stackoverflow.com/questions/550632/favorite-django-tips-features

 Implementing this will improve user experience and simplify deployment.

 The fact that people can change the code is not an excuse not to do the
 right thing.

-- 
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-upda...@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] #13977: Indeterministic PicklingError

[Django]

#13977: Indeterministic PicklingError
-+--
 Reporter:  etam |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.sessions  | Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 There is something wrong with session:

 {{{
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162] mod_wsgi
 (pid=3072): Exception occurred processing WSGI script
 '/home/www/shop/django.wsgi'., referer:
 http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162] Traceback (most
 recent call last):, referer: http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162]   File
 "/usr/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 245,
 in __call__, referer: http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162] response =
 middleware_method(request, response), referer:
 http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162]   File
 "/usr/lib/python2.5/site-packages/django/contrib/sessions/middleware.py",
 line 36, in process_response, referer:
 http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162]
 request.session.save(), referer:
 http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162]   File
 "/usr/lib/python2.5/site-packages/django/contrib/sessions/backends/db.py",
 line 57, in save, referer: http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162] session_data
 = self.encode(self._get_session(no_load=must_create)),, referer:
 http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162]   File
 "/usr/lib/python2.5/site-
 packages/django/contrib/sessions/backends/base.py", line 88, in encode,
 referer: http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162] pickled =
 pickle.dumps(session_dict, pickle.HIGHEST_PROTOCOL), referer:
 http://shop.domain.com/accounts/checkout/?
 [Thu Jul 08 19:15:38 2010] [error] [client 79.162.31.162] PicklingError:
 Can't pickle : it's not the same object as
 decimal.Decimal, referer: http://shop.domain.com/accounts/checkout/?
 }}}

 It happens sometimes, not always.

-- 
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-upda...@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] #13975: Long names are generated differently in Django 1.1 and Django 1.2, causing incompatability

[Django]

#13975: Long names are generated differently in Django 1.1 and Django 1.2, 
causing
incompatability
--+-
  Reporter:  yn...@opera.com  | Owner:  nobody
Status:  new  | Milestone:
 Component:  Uncategorized|   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by ramiro):

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

Comment:

 Replying to [ticket:13975 yn...@opera.com]:
 > It is possible that http://code.djangoproject.com/changeset/13328 may
 have fixed part of the problem, but when testing the last_insert_id() part
 of that fix, it did not work with names that contain upper case
 characters. I have not tested the full fix.

 That has been already reported in #13821 that contains a patch that should
 be ready for being checked in 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-upda...@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] #9847: hardcoded string in core/handlers/base.py

[Django]

#9847: hardcoded string in core/handlers/base.py
-+--
  Reporter:  drakkan | Owner: 
Status:  new | Milestone:  1.3
 Component:  Core framework  |   Version:  1.0
Resolution:  |  Keywords: 
 Stage:  Accepted| Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by vkryachko):

  * 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-upda...@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] #13976: Admin view with relations (ForeignKey or ManyToMany) does not limit number of entries in document

[Django]

#13976: Admin view with relations (ForeignKey or ManyToMany) does not limit 
number
of entries in document
--+-
  Reporter:  yn...@opera.com  | Owner:  nobody
Status:  new  | Milestone:
 Component:  Uncategorized|   Version:  1.1   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  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-upda...@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] #13976: Admin view with relations (ForeignKey or ManyToMany) does not limit number of entries in document

[Django]

#13976: Admin view with relations (ForeignKey or ManyToMany) does not limit 
number
of entries in document
-+--
 Reporter:  yn...@opera.com  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  1.1   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 When opening for view or edit a record in the admin view of a model with a
 ForeignKey or ManyToMany relation to another table, the view lists
 '''all''' entries from the other table in the dropdown/selection box, no
 matter how many entries there are in that table.

 The result is that if the reference table contain hundreds of thousands,
 or millions of entries, the record cannot be viewed, or edited, in the
 admin view, because it tries to generate a document that may run into
 Gigabytes, as well as require accessing each record in that table to get
 information about it.

 My suggestion is that the admin view should restrict the number of
 elements in such automatically generated dropdown/selection boxes to at
 most 100 elements, preferably less than 50, and provide an alternative
 selection mechanism if the number of elements exceeds this limit.

 The admin view may not be intended for such cases, but I would suggest
 that it ought to be able to handle such situations gracefully.

 Another area where such numbers cause problems is when deleting a record
 that references, or is referenced by, large numbers of records.

-- 
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-upda...@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] r13444 - django/branches/releases/1.2.X/django/contrib/gis/db/backends/mysql

[noreply]

Author: jbronn
Date: 2010-07-21 10:28:06 -0500 (Wed, 21 Jul 2010)
New Revision: 13444

Modified:
   
django/branches/releases/1.2.X/django/contrib/gis/db/backends/mysql/creation.py
Log:
[1.2.X] Fixed #13967 -- MySQL spatial backend now respects when 
`spatial_index=False`.  Thanks, Simon Law, for bug report and patch.

Backport of r13443 from trunk.


Modified: 
django/branches/releases/1.2.X/django/contrib/gis/db/backends/mysql/creation.py
===
--- 
django/branches/releases/1.2.X/django/contrib/gis/db/backends/mysql/creation.py 
2010-07-21 15:23:18 UTC (rev 13443)
+++ 
django/branches/releases/1.2.X/django/contrib/gis/db/backends/mysql/creation.py 
2010-07-21 15:28:06 UTC (rev 13444)
@@ -6,7 +6,7 @@
 from django.contrib.gis.db.models.fields import GeometryField
 output = super(MySQLCreation, self).sql_indexes_for_field(model, f, 
style)
 
-if isinstance(f, GeometryField):
+if isinstance(f, GeometryField) and f.spatial_index:
 qn = self.connection.ops.quote_name
 db_table = model._meta.db_table
 idx_name = '%s_%s_id' % (db_table, f.column)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r13443 - django/trunk/django/contrib/gis/db/backends/mysql

[noreply]

Author: jbronn
Date: 2010-07-21 10:23:18 -0500 (Wed, 21 Jul 2010)
New Revision: 13443

Modified:
   django/trunk/django/contrib/gis/db/backends/mysql/creation.py
Log:
Fixed #13967 -- MySQL spatial backend now respects when `spatial_index=False`.  
Thanks, Simon Law, for bug report and patch.


Modified: django/trunk/django/contrib/gis/db/backends/mysql/creation.py
===
--- django/trunk/django/contrib/gis/db/backends/mysql/creation.py   
2010-07-20 21:04:51 UTC (rev 13442)
+++ django/trunk/django/contrib/gis/db/backends/mysql/creation.py   
2010-07-21 15:23:18 UTC (rev 13443)
@@ -6,7 +6,7 @@
 from django.contrib.gis.db.models.fields import GeometryField
 output = super(MySQLCreation, self).sql_indexes_for_field(model, f, 
style)
 
-if isinstance(f, GeometryField):
+if isinstance(f, GeometryField) and f.spatial_index:
 qn = self.connection.ops.quote_name
 db_table = model._meta.db_table
 idx_name = '%s_%s_id' % (db_table, f.column)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13975: Long names are generated differently in Django 1.1 and Django 1.2, causing incompatability

[Django]

#13975: Long names are generated differently in Django 1.1 and Django 1.2, 
causing
incompatability
-+--
 Reporter:  yn...@opera.com  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Using long class names and member names in models can create composite
 table and sequence names that are longer than 63 characters, particularly
 for ManyToMany relations in Postgresql (v8.3)

 When such a model that has been created in Django 1.1 is used in a Django
 1.2 such names, particularly the id_seq, but probably others, are not
 found by v1.2 because it constructs a name different from what Django 1.1
 originally created. I have also seen indications that this will break for
 models created entirely in Django 1.2, as well.

 The attached testcase performs 4 different tests, the first three works in
 both v1.1 and v1.2, the fourth only works in v1.1.

 It is possible that this problem is related to what
 http://code.djangoproject.com/changeset/13328 fixes, and probably related
 to the change to limit names to 63 characters.

 I would recommend that Django at the very least should be able to use
 models that have been instantiated in an older version, and the names used
 there. Using the newer name convention should be done when 1.2 creates the
 tables.

 For reference here are the emails I posted to django-users (At present I
 have downgraded the v1.2.1 systems back to v1.1.1) :

 
 By accident I have ended up with a mixed Django 1.1.1 and Django 1.2.1
 environment, on different machines.

 I am currently considering whether to downgrade the 1.2 installations, or
 upgrade the older ones, or keep the current setup, but this depends on
 finding a solution to an apparent incompatibility between 1.1 and 1.2, and
 whether or not the upgrade can cause other problems.

 The current applications, including the configuration of the Postgresql
 8.3, have all been developed in v1.1.1

 While this have not caused problems for one of my applications (AFAICT),
 I've discovered that v1.2 is apparently not compatible with the ManyToMany
 relations used in a second application, causing an exception to be thrown
 when adding to the many to many field:


 {{{
   File "/usr/lib/pymodules/python2.5/django/db/models/fields/related.py",
 line 490, in add
 self._add_items(self.source_field_name, self.target_field_name, *objs)
   File "/usr/lib/pymodules/python2.5/django/db/models/fields/related.py",
 line 574, in _add_items
 '%s_id' % target_field_name: obj_id,
   File "/usr/lib/pymodules/python2.5/django/db/models/query.py", line 352,
 in create
 obj.save(force_insert=True, using=self.db)
   File "/usr/lib/pymodules/python2.5/django/db/models/base.py", line 435,
 in save
 self.save_base(using=using, force_insert=force_insert,
 force_update=force_update)
   File "/usr/lib/pymodules/python2.5/django/db/models/base.py", line 528,
 in save_base
 result = manager._insert(values, return_id=update_pk, using=using)
   File "/usr/lib/pymodules/python2.5/django/db/models/manager.py", line
 195, in _insert
 return insert_query(self.model, values, **kwargs)
   File "/usr/lib/pymodules/python2.5/django/db/models/query.py", line
 1479, in insert_query
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/usr/lib/pymodules/python2.5/django/db/models/sql/compiler.py",
 line 789, in execute_sql
 self.query.model._meta.db_table, self.query.model._meta.pk.column)
   File
 "/usr/lib/pymodules/python2.5/django/db/backends/postgresql/operations.py",
 line 57, in last_insert_id
 cursor.execute("SELECT CURRVAL('\"%s_%s_seq\"')" % (table_name,
 pk_name))
   File
 "/usr/lib/pymodules/python2.5/django/db/backends/postgresql_psycopg2/base.py",
 line 44, in execute
 return self.cursor.execute(query, args)
 django.db.utils.DatabaseError: relation "model_bar_foo_id_s" does not
 exist

 }}}

 A condensed example of my code (not tested independently) is the
 following:


 {{{
   class foo(models.Model):
 #declarations

   class bar(models.Model):
 foo_list = models.ManyToManyField(foo, null=True)

 def update_foo(x):
 self.foo_list.add(x)

 }}}

 The call to "self.foo_list.add()" is what triggers the above exception.

 AFAICT the SQL code generated by sqlall by v1.1.1 is equivalent to the
 code generated by 1.2.1 (in v1.2.1 there is a use of ALTER in the bar-
 reference of the many-to-many table). There is however no mention in the
 sqlall output of an identifier with the name reported by the exception,
 though it is possible that it may be an identifier generated server-side,
 or that it would be generated in a resetdb situation.

 I 

Re: [Django] #13973: Get current language name filter in templates

[Django]

#13973: Get current language name filter in templates
+---
  Reporter:  Secator   | Owner:  
nobody   
Status:  closed | Milestone:  1.3   
   
 Component:  Translations   |   Version:  1.2   
   
Resolution:  duplicate  |  Keywords:  
language name
 Stage:  Unreviewed | Has_patch:  0 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by ramiro):

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

Comment:

 This is part of what has been proposed and discussed on #4030.

 That ticket has been accepted by two core developers and has a patch that
 contains documentation and test (although it could be outdated, perhaps we
 could revive it and propose for 1.3). For that reason I'm closing this
 ticket as duplicate.

-- 
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-upda...@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] #13906: REPEATABLE READ (as used by default on MySQL) breaks atleast QuerySet.get_or_create().

[Django]

#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
---+
  Reporter:  sebastian_noack   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by sebastian_noack):

 Can you explain a bit more what you are trying to show and what you expect
 to happen instead? Could you maybe also provide a text file with the
 complete sql sessions instead of some commented pseudo code, to better
 reproduce what you are talking about? 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 post to this group, send email to django-upda...@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] #13974: saving object with multi-table inheritance is not transactional by default

[Django]

#13974: saving object with multi-table inheritance is not transactional by 
default
--+-
 Reporter:  ccurvey   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 if you are using multi-table inheritance, and there is some problem
 writing to one of the tables, some tables are updated, and some are not.

 (MySQL 5.x on Ubuntu, Django 1.2rc 1 on Windows)

 1) Set up a new project with database settings like so:

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.mysql',
 'NAME': 'mydb',
 'USER': 'myuser',
 'PASSWORD': 'mypassword'
 'HOST': 'myhost',
 'PORT': '',
 'OPTIONS' : {
 'init_command' : 'set storage_engine=INNODB',
 },

 }
 }
 }}}

 2) Now set up some models that use inheritance:

 {{{
 from django.db import models

 # Create your models here.

 class Foo(models.Model):
 a = models.IntegerField()

 class Bar(Foo):
 b = models.IntegerField()

 }}}

 3) Now create a script that does something obviously wrong.

 {{{
 import sys
 sys.path.append(r"C:\users\ccurvey")
 sys.path.append(r"C:\users\ccurvey\testme")
 sys.path.append(r"C:\users\ccurvey\testme\foobar")

 import os
 os.environ["DJANGO_SETTINGS_MODULE"] = 'settings'

 from foobar.models import Bar

 # try testing something that is clearly wrong.
 bar = Bar(a=1, b="A")

 # this is going to throw a ValueError
 bar.save()

 }}}

 4) Now go look at the underlying tables in MySQL:

 {{{
 mysql> select * from foobar_foo;
 ++---+
 | id | a |
 ++---+
 |  1 | 1 |
 ++---+
 1 row in set (0.00 sec)

 mysql> select * from foobar_bar;
 Empty set (0.00 sec)

 }}}

 The workaround is to add @commit_on_success and a save() method to Bar,
 like so, but it seems (to me) like this should be unncessary.

 {{{
 from django.db.transaction import commit_on_success


 class Bar(Foo):
 b = models.IntegerField()

 @commit_on_success
 def save(self):
 super(Bar, self).save()

 }}}

-- 
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-upda...@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] #13906: REPEATABLE READ (as used by default on MySQL) breaks atleast QuerySet.get_or_create().

[Django]

#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
---+
  Reporter:  sebastian_noack   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by akaariai):

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

Comment:

 Setting transaction level to READ COMMITED does not solve your problem. A
 sequence showing erroneous behaviour in REPEATABLE READ:

 t1: SELECT * FROM foo WHERE condition # transaction 1 get part.[[BR]]
 t1: INSERT INTO ... # create[[BR]]
 t2: SELECT * FROM foo WHERE condition # transaction 2 get part, t2 sees
 nothing here.[[BR]]
 t1: commit()[[BR]]

 What would (at least partly) solve your problem is unique index on the
 where condition, then the DB would be able to block the t2's create.

-- 
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-upda...@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] #13973: Get current language name filter in templates

[Django]

#13973: Get current language name filter in templates
---+
 Reporter:  Secator   |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Translations   | Version:  1.2   
 Keywords:  language name  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Currently there's no way to retrieve current language name easily in
 templates. You can only use {% get_current_language ... %} filter to get
 the language code (eg. 'en-us' or 'de-de').
 There should be a template filter in django.templatetags.i18n to get the
 "English" or "German" strings (verbose name of the language).

 Example:

 {{{
 #settings.py:
 LANGUAGES = (
   ('de', 'German'),
   ('en', 'English'),
 )

 #templates:
 {% get_current_language as LANGUAGE_CODE %} # Existing filter. Returns en-
 us if language is english.
 {% get_current_language_name as LANGUAGE_NAME %} # Proposed filter. Should
 return 'English' if LANGUAGE_CODE is 'en'. Basically should return the
 second element of settings.LANGUAGES touples.
 }}}

-- 
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-upda...@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] #13954: Typo in email backend documentation

[Django]

#13954: Typo in email backend documentation
+---
  Reporter:  mostrovsky | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Ready for checkin
  * 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-upda...@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] #7018: Make ModelForm multiple inheritance possible

[Django]

#7018: Make ModelForm multiple inheritance possible
-+--
  Reporter:  bear330 | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mitar):

  * summary:  Make ModelForm multiple inheritance is possible. => Make
  ModelForm multiple inheritance possible

Comment:

 I made a metaclass which allows multiple ModelForm forms to be combined. I
 also made a mixin which then allows resulting form to be used on multiple
 instances (for each parent ModelForm one) which are then used to populate
 form fields, validation and also they are all updated by simply calling
 `form.save()`. All this is heavily hackish but it works and it proves this
 is doable and could go also into official version (where it would be much
 less hackish). I am attaching the code.

 The problem is that it is hard to reason about such forms and code and
 even decide which behavior is proper (for example: how to order fields in
 a form with multiple parents and even with some manually declared fields?
 what if fields definitions overlap?). (It is useful to use
 FieldsetFormMixin described bellow to remedy this.)

 All this can be used with my [comment:ticket:6630:12 mixin for fieldsets]
 so that every parent form can be put into its own fieldset. Then it is
 possible to do such form which allows user and profile changes at the same
 time:

 {{{
 class UserAndProfileChangeForm(metaforms.FieldsetFormMixin,
 metaforms.ParentsIncludedModelFormMixin, UserChangeForm,
 UserProfileChangeForm):
   error_css_class = 'error'
   required_css_class = 'required'
   fieldset = UserChangeForm.fieldset + [(
 utils_text.capfirst(UserProfileChangeForm.Meta.model._meta.verbose_name),
 {
   'fields': UserProfileChangeForm.base_fields.keys(),
 })]

   __metaclass__ = metaforms.ParentsIncludedModelFormMetaclass
 }}}

 And save on such form validates and saves both objects. Ah, one more
 thing, form initialization changes somewhat. `instance` attribute gets a
 list of instances:

 {{{
 forms.UserAndProfileChangeForm(request.POST, instance=[request.user,
 request.user.get_profile()])
 }}}

 But be careful if you pass objects directly from request, those instances
 are changed by `form.is_valid` method even if form does not validate which
 could allow user to alter some context (post)processors behavior. So it is
 necessary to do something like:

 {{{
 if request.method == 'POST':
   stored_user = copy.copy(request.user)
   form = forms.UserAndProfileChangeForm(request.POST,
 instance=[request.user, request.user.get_profile()])
   if form.is_valid():
 objs = form.save()
 return shortcuts.redirect(objs[-1]) # The last element is user profile
 object
   else:
 # Restore user request object as it is changed by form.is_valid
 request.user = stored_user
 if hasattr(request.user, '_profile_cache'):
   # Invalidates profile cache
   delattr(request.user, '_profile_cache')
 else:
   form = forms.UserAndProfileChangeForm(instance=[request.user,
 request.user.get_profile()])
 }}}

 Also user registration form (for use with django-registration) is doable:

 {{{
 class UserRegistrationForm(metaforms.FieldsetFormMixin,
 metaforms.ParentsIncludedModelFormMixin, UserCreationForm,
 UserProfileChangeForm):
   error_css_class = 'error'
   required_css_class = 'required'
   fieldset = UserCreationForm.fieldset + [(
 utils_text.capfirst(UserProfileChangeForm.Meta.model._meta.verbose_name),
 {
   'fields': UserProfileChangeForm.base_fields.keys(),
 })]

   def save(self, commit=True):
 # We disable save method as registration backend module should take
 care of user and user
 # profile objects creation and we do not use this form for changing
 data
 assert False
 return None

   __metaclass__ = metaforms.ParentsIncludedModelFormMetaclass
 }}}

 With django-registration backend having such `register` method:

 {{{
 def register(self, request, **kwargs):
   user = super(ProfileBackend, self).register(request, **kwargs)
   profile, created =
 utils.get_profile_model().objects.get_or_create(user=user)

   # lambda-object to the rescue
   form = lambda: None
   form.cleaned_data = kwargs

   # First name, last name and e-mail address are stored in user object
   forms_models.construct_instance(form, user)
   user.save()

   # Other fields are stored in user profile object
   forms_models.construct_instance(form, profile)
   profile.save()

   return user
 }}}

-- 
Ticket URL: 

Re: [Django] #13972: Field initial value callable should take a request object as an argument

[Django]

#13972: Field initial value callable should take a request object as an argument
-+--
  Reporter:  mitar   | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mitar):

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

Comment:

 An example how this can be useful can be found in [comment:ticket:5446:25
 #5446].

-- 
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-upda...@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] #5446: New model fields for languages and countries at least

[Django]

#5446: New model fields for languages and countries at least
--+-
  Reporter:  Raphaël Hertzog   | Owner:  
marinho
Status:  reopened | Milestone:  
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:   |  Keywords:  
feature_request
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by mitar):

 I am attaching a new version of geo fields. I over all data and I
 corrected it according to Wikipedia values (some values were missing or
 were invalid or not best possible). I also extended them also to a city
 field for which I added necessary data with major (not necessary capital
 in all cases) city for every country.

 I also extended initial values to be a callable which takes a request as a
 parameter so that it is possible to do GeoIP based initial values. I
 explained this and how it is possible to make this work in #13972. If
 request is not specified it falls back to values from settings so it is
 also backwards compatible. (Only loading of GeoIP could probably also be
 made optional.)

-- 
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-upda...@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] #13972: Field initial value callable should take a request object as an argument

[Django]

#13972: Field initial value callable should take a request object as an argument
---+
 Reporter:  mitar  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Currently it is possible to define initial value for a field as a
 callable. But this is quite limited in use as it does not take any context
 in which it should run.

 I am proposing that it should take a request object. In this way it is
 possible to set initial values based on a request. For example, based on
 GeoIP information. We should pass a request object to the form constructor
 which would then pass it along to the those callables.

 I am attaching a short helper function which allows me that I define such
 callables already. It postprocesses the form class so that request is
 available to callables. So in the view it is necessary just to construct
 your form with:

 {{{
 form = initial_accepts_request(request, MyForm)()
 }}}

 It still allows initial values to be passed at construction time and they
 override callables.

 But it would be much better if this would be officially supported.

-- 
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-upda...@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] #6630: Fieldsets for newforms

[Django]

#6630: Fieldsets for newforms
+---
  Reporter:  Petr Marhoun   | Owner:  
nobody 
Status:  new| Milestone:
 
 Component:  Forms  |   Version:  
SVN
Resolution: |  Keywords:  
feature
 Stage:  Design decision needed | Has_patch:  1 
 
Needs_docs:  1  |   Needs_tests:  0 
 
Needs_better_patch:  1  |  
+---
Comment (by mitar):

 Ah, yes. This code can currently be used as a mixin. So you just do:

 {{{
 class MyFieldsetForm(metaforms.FieldsetFormMixin, MyForm):
   fieldset = ... # same structure as for django.contrib.admin.ModelAdmin
 }}}

-- 
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-upda...@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] #6630: Fieldsets for newforms

[Django]

#6630: Fieldsets for newforms
+---
  Reporter:  Petr Marhoun   | Owner:  
nobody 
Status:  new| Milestone:
 
 Component:  Forms  |   Version:  
SVN
Resolution: |  Keywords:  
feature
 Stage:  Design decision needed | Has_patch:  1 
 
Needs_docs:  1  |   Needs_tests:  0 
 
Needs_better_patch:  1  |  
+---
Comment (by mitar):

 Replying to [comment:10 Petr Marhoun ]:
 > Please - compare my very simple patch (02-add-fieldsets.diff) and very
 complex implementation in django.contrib.admin.helpers.

 I have even a simpler approach. Simply add to every field an attribute
 `fieldset` which describes in which fieldset this field is and then use
 `ifchanged` template tag to render fieldsets. I am attaching code for that
 which populates this attribute accordingly.

 And then you can simply do:

 {{{
 ...
 {% for field in form.visible_fields %}
   {% ifchanged field.fieldset.name %}
 {% if not forloop.first %}
   
   
 {% endif %}
 
 {% if field.fieldset.name %}{{ field.fieldset.name
 }}{% endif %}
 
   {% endifchanged %}
 ...
 }}}

 I am also attaching a simple form template which uses this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13970: Overridden widgets in ModelForm do not respect blank flag of model field

[Django]

#13970: Overridden widgets in ModelForm do not respect blank flag of model field
-+--
  Reporter:  mitar   | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mitar):

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

-- 
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-upda...@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] #13970: Overridden widgets in ModelForm do not respect blank flag of model field

[Django]

#13970: Overridden widgets in ModelForm do not respect blank flag of model field
-+--
  Reporter:  mitar   | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  invalid |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by mitar):

 Replying to [comment:1 carljm]:
 > If you are only changing the widget, use the "widget" attribute of the
 inner Meta class, as documented in that same section, instead of
 overriding the entire field, and you won't see this problem.

 No, exactly this is the problem. I also thought so. That I will change
 only widget and everything will work. But see, when changing the widget
 you initialize it to an object. And so later on `required` value on a
 widget is not set properly based on a model field. For example I had to do
 this:

 {{{
 class UserProfileChangeForm(forms_models.ModelForm):
   class Meta:
 model = models.UserProfile
 widgets = {
   'birthday': widgets.SelectDateWidget(
 years=range(datetime.date.today().year, 1900, -1),
 required=(not filter(lambda x: x.name == 'birthday',
 models.UserProfile._meta.fields)[0].blank),
   ),
 }
 }}}

 So SelectDateWidget takes `required` argument. Once you do
 `SelectDateWidget()` ModelForm takes the widget as it is. And `required`
 argument is by default set to `True.` What I am proposing is that if I do:

 {{{
 widgets = {
   'birthday': widgets.SelectDateWidget(required=True),
 }
 }}}

 Widget should behave as required.

 If I do:

 {{{
 widgets = {
   'birthday': widgets.SelectDateWidget(required=False),
 }
 }}}

 Widget should behave as not required.

 But if I do:

 {{{
 widgets = {
   'birthday': widgets.SelectDateWidget(),
 }
 }}}

 Widget should not be by default required but that of the model field.

-- 
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-upda...@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.