[Django] #13879: method_decorator doesn't supports decorators with arguments

[Django]

#13879: method_decorator doesn't supports decorators with arguments
---+
 Reporter:  marinho|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I tried use '''django.utils.decorators.method_decorator''' to support
 decorator '''permission_required''' and figured out it's not supporting
 decorators passing arguments like it does:

 @permission_required(something_here)

 Instead its code waits for you just pass a function as an only one
 argument, like this:

 @login_required

 I made my own version of it, that's below:

 {{{
 from functools import wraps, update_wrapper

 def method_decorator(decorator):
 """Converts a function decorator into a method decorator.

 This works properly for both: decorators with arguments and without
 them. The Django's version
 of this function just supports decorators with no arguments."""

 # For simple decorators, like @login_required, without arguments
 def _dec(func):
 def _wrapper(self, *args, **kwargs):
 def bound_func(*args2, **kwargs2):
 return func(self, *args2, **kwargs2)
 return decorator(bound_func)(*args, **kwargs)
 return wraps(func)(_wrapper)

 # Called everytime
 def _args(*argsx, **kwargsx):
 # Detect a simple decorator and call _dec for it
 if len(argsx) == 1 and callable(argsx[0]) and not kwargsx:
 return _dec(argsx[0])

 # Used for decorators with arguments, like
 @permission_required('something')
 def _dec2(func):
 def _wrapper(self, *args, **kwargs):
 def bound_func(*args2, **kwargs2):
 return func(self, *args2, **kwargs2)
 return decorator(*argsx, **kwargsx)(bound_func)(*args,
 **kwargs)
 return wraps(func)(_wrapper)
 return _dec2

 update_wrapper(_args, decorator)
 # Change the name to aid debugging.
 _args.__name__ = 'method_decorator(%s)' % decorator.__name__
 return _args
 }}}

 If necessary I can make a patch and attach to this ticket.

-- 
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] #13878: Formset validation refactoring and valid_forms property of fieldsets

[Django]

#13878: Formset validation refactoring and valid_forms property of fieldsets
+---
  Reporter:  Petr Marhoun   | Owner:  
nobody
Status:  new| Milestone:

 Component:  Forms  |   Version:  
SVN   
Resolution: |  Keywords:

 Stage:  Unreviewed | Has_patch:  1 

Needs_docs:  0  |   Needs_tests:  0 

Needs_better_patch:  0  |  
+---
Changes (by Petr Marhoun ):

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

Comment:

 The first patch (01-formset-refactoring.diff) contains changes of code.
 The second patch (02-formset-refactoring-cleaned-data-tests.diff) shows
 that cleaned_data as attribute of formsets or forms in formsets are
 problematic (this patch could be applied to trunk to expose the
 situation). The third patch (03-formset-refactoring-valid-forms-
 tests.diff) contains tests for new property valid_forms.

-- 
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] #13878: Formset validation refactoring and valid_forms property of fieldsets

[Django]

#13878: Formset validation refactoring and valid_forms property of fieldsets
---+
 Reporter:  Petr Marhoun   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 This series of patch solves two problems:
  * Formsets validation is spread in four different methods so it is very
 difficult to comprehend the code and to solve possible problems.
  * There is no method which gives valid forms in all situation -
 especially, valid formset can contain invalid form if this form should be
 deleted. So this ticket adds new property valid_forms which returns all
 valid (and filled) forms, possible ordered.

 There is wiki page and discussion in django-developers:
  *
 
http://code.djangoproject.com/wiki/ImprovementsForDjangoForms#BetterAPIforformsets
  * http://groups.google.com/group/django-
 developers/browse_thread/thread/37e1e8b8313c38de

-- 
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 Petr Marhoun ):

 Patch 02-add-fieldsets.diff: This patch adds support for fieldsets. Syntax
 is inspired by django-forms-utils (and different from previous proposal -
 so it is possible to use names for fieldsets):

 {{{
 class FieldsetsTestForm(TestForm):
 class Meta:
 fieldsets = (
 ('main', {
 'fields': ('field3', 'field8', 'field2'),
 'legend': 'Main fields',
 'description': 'You should really fill these fields.',
 }),
 ('other', {
 'fields': ('field5', 'field11', 'field14'),
 'legend': 'Other fields',
 'attrs': {'class': 'other'},
 }),
 )
 }}}

 Parameter fieldsets is list of items - each item has name and options.
 There is one required option "fields" giving list of fields. There are
 three optional options "description", "legend" and "attrs" which can be
 used for useful information.

 Methods Form.as_ul, Form.as_table and Form.as_p are not changed - they are
 only for simple forms and they continue to work also with fieldsets as
 plain lists. But there are new methods - has_fieldsets (boolean property)
 and fieldsets. Fieldsets is method giving collection of fieldsets, each
 fieldset is collection of fields - it is possible to iterate or use names
 of fieldsets or fields in fieldsets.

 Changes compared to discussion and django-forms-utils:
  * There is "attrs" option - it is the most general option. But it is a
 design decision which could be changed without any problem, it means
 changes only in two places. I am not really sure if options "legend",
 "description" and "attrs" are the right choice (so I sometimes change my
 opinion.)
  * Forms without fieldset meta attribute have one dummy fieldset but
 has_fieldsets property is False - so it is possible to identify form
 without fieldsets and also to use general templates which want to use
 fieldsets only.
  * There is no length of fieldset collection - is it really useful? For
 example, there is no length of form as collection of fields.
  * There is no caching of fieldsets - it does not seem to be necessary,
 fieldsets are used only once in more cases. And I try to create patch so
 simple as possible.

 Patch 03-use-core-fieldsets-in-admin.diff: This patch adds support for
 using of fieldsets in admin. It is similar to current situation with
 "fields" and "exclude" - if !ModelAdmin has "fieldsets" or "fields", they
 are used. Otherwise meta parameters "fields" and "exclude" from form are
 de facto respected - this patch is explicit but with similar effects, meta
 parameter "fieldsets" is respected.

 There was one expected requirement - there should be only one
 implementation of fieldsets in Django, core fieldsets should be reused in
 admin. I absolutely agree that it seems to be logical requirement - but I
 really think that requirements for core fieldsets and admin fieldsets are
 totally different, there is only one common thing - using of HTML fieldset
 tag. Admin fieldsets are collection of fieldlines (each fieldline has
 fields), core fieldsets are collection of fields. Core fieldsets are only
 very light iterators without any specific feature (with exception of
 options - but they are only saved for using in templates, they are not
 used in core) - admin fieldsets support for example javascript for
 collapsing of fields, dependency between fields (for slug fields), not
 editable fields and more. Please - compare my very simple patch (02-add-
 fieldsets.diff) and very complex implementation in
 django.contrib.admin.helpers.

 This third patch is without tests - I am prepared to create them if the
 idea to have two different implementation of fieldsets is accepted. (But I
 tested it with my code and it works without problems.)

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

Re: [Django] #13877: More documentation needed on exceptions in middlewares

[Django]

#13877: More documentation needed on exceptions in middlewares
---+
  Reporter:  pakal   | 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 pakal ):

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

Comment:

 My tests show that if process_request, process_view or process_exception
 raise an error, normal handling of this error occurs, depending on the
 "DEBUG" setting : printing full stack information, or sending an email to
 admins.

 But if process_response raises an error, there is visibly no fallback
 solution : the server simply outputs a raw traceback, and admins are not
 notified of the error.
 Shouldn't the exception management system protect "process_response" too,
 so that admin notification and the display of a simple "error 500" page
 occurs ?

-- 
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] #13877: More documentation needed on exceptions in middlewares

[Django]

#13877: More documentation needed on exceptions in middlewares
--+-
 Reporter:  pakal   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Uncategorized | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have not found any documentation on the behaviour of django when an
 exception is raised, not from a view, but from a middleware method.

 Eg. if a process_exception() raises an unexpected exception, how will
 django deal with that ? And if a process_response() fails when treating a
 normal http response ?

 I can have some information by testing these tests, but as long as it's
 undocumented I can't really rely on 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-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] #13876: Documentation duplicates

[Django]

#13876: Documentation duplicates
---+
  Reporter:  pakal   | 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 Alex):

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

Old description:

> In documentation page "the Django admin site" : a section is written
> twice in a row, the one starting with :
> "If the string given is a method of the model, ModelAdmin or a callable,
> Django will HTML-escape the output by default. If you'd rather not escape
> the output of the method, give the method an allow_tags attribute whose
> value is True."
>

> Besides, in request-response doc , two different sections deal with
> setting/reading request headers, maybe they should be merged :
>
> """
> Here's a full example model:
>
> You can add and delete headers using dictionary syntax:
>
> >>> response = HttpResponse()
> >>> response['X-DJANGO'] = "It's the best."
> >>> del response['X-PHP']
> >>> response['X-DJANGO']
> "It's the best."
>
> Note that del doesn't raise KeyError if the header doesn't exist.
>
> []
>
> Setting headers
>
> To set a header in your response, just treat it like a dictionary:
> """
>
> Cheers,
> Pascal

New description:

 In documentation page "the Django admin site" : a section is written twice
 in a row, the one starting with :
 "If the string given is a method of the model, ModelAdmin or a callable,
 Django will HTML-escape the output by default. If you'd rather not escape
 the output of the method, give the method an allow_tags attribute whose
 value is True."


 Besides, in request-response doc , two different sections deal with
 setting/reading request headers, maybe they should be merged :
 {{{
 """
 Here's a full example model:

 You can add and delete headers using dictionary syntax:

 >>> response = HttpResponse()
 >>> response['X-DJANGO'] = "It's the best."
 >>> del response['X-PHP']
 >>> response['X-DJANGO']
 "It's the best."

 Note that del doesn't raise KeyError if the header doesn't exist.

 []

 Setting headers

 To set a header in your response, just treat it like a dictionary:
 """
 }}}
 Cheers,
 Pascal

Comment:

 Added formatting.

-- 
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] #13876: Documentation duplicates

[Django]

#13876: Documentation duplicates
--+-
 Reporter:  pakal   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Uncategorized | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 In documentation page "the Django admin site" : a section is written twice
 in a row, the one starting with :
 "If the string given is a method of the model, ModelAdmin or a callable,
 Django will HTML-escape the output by default. If you'd rather not escape
 the output of the method, give the method an allow_tags attribute whose
 value is True."


 Besides, in request-response doc , two different sections deal with
 setting/reading request headers, maybe they should be merged :

 """
 Here's a full example model:

 You can add and delete headers using dictionary syntax:

 >>> response = HttpResponse()
 >>> response['X-DJANGO'] = "It's the best."
 >>> del response['X-PHP']
 >>> response['X-DJANGO']
 "It's the best."

 Note that del doesn't raise KeyError if the header doesn't exist.

 []

 Setting headers

 To set a header in your response, just treat it like a dictionary:
 """

 Cheers,
 Pascal

-- 
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] #13875: cannot customize admin submit_row

[Django]

#13875: cannot customize admin submit_row
---+
  Reporter:  drul  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by drul):

 * cc: tomasz.k...@invert-it.pl (added)
  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * needs_tests:  => 0
  * needs_docs:  => 0

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #13875: cannot customize admin submit_row

[Django]

#13875: cannot customize admin submit_row
--+-
 Reporter:  drul  |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 django submit_row inclusion tag doesn't pass extra_context from
 ModelAdmin.(add|change|..)_view to submit_row.html template. Because of
 that, i cannot add extra button to submit row (i.e. print invoice). this
 tag should pass whole context to the template

-- 
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 Petr Marhoun ):

 Added new series of patches. They are based on previous ones, description
 on wiki page, forms-utils and discussion in django-developers:
  * http://code.djangoproject.com/wiki/ImprovementsForDjangoForms#Fieldsets
  * http://bitbucket.org/carljm/django-form-
 utils/src/tip/form_utils/forms.py
  * http://groups.google.com/group/django-
 developers/browse_thread/thread/37e1e8b8313c38de

 Description of individual patches follows:

 Patch 01-move-fields-and-exclude.diff: This patch moves meta attributes
 "fields" and "exclude" from !ModelForm to Form. It is the most complex
 patch.

 There are some changes which could be bug fixes or backward
 incompatibilities:
  * Attributes "fields" and "exclude" apply also for fields defined on
 !ModelForm. It solves (accepted) ticket #8620.
  * With multiply inheritance fields are sorted by method resolution order,
 not by a custom way. I think it is the right approach (and it simplifies
 code) but I am prepared to change it back.

 I also do not know if some classes and methods are part of public API. I
 reworked django.forms.forms.get_declared_fields and renamed
 django.forms.forms.!DeclarativeFieldsMetaclass to !FormMetaclass (it makes
 more things after the change). I also stop using parameters "fields" and
 "exclude" of django.forms.models.fields_for_model but this method is
 exported from this module so I do not change 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-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] #13769: ModelForm: override default field attributes

[Django]

#13769: ModelForm: override default field attributes
-+--
  Reporter:  darkrho | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:  modelform fields_attrs
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Petr Marhoun ):

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

Comment:

 Added another patch for the same feature - I implemented it independently
 (and found this ticket later). My patch has tests and use different name
 for proposed feature (fields_kwargs instead fields_attrs - but it is not
 important for me and I do not know what is better).

 There is also some motivation here:
 http://code.djangoproject.com/wiki/ImprovementsForDjangoForms
 #Modelfieldswithnot-defaultvalues

 I think also there is a problem in the original patch - function should
 not have dictionary as default argument because dictionary is mutable.

-- 
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] #12856: Missing form.field tags?

[Django]

#12856: Missing form.field tags?
+---
  Reporter:  mnbayazit  | Owner:  nobody
Status:  new| Milestone:
 Component:  Forms  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Petr Marhoun ):

 Added patch which implements !BoundField.required (with tests, without
 documentation).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #13674: Javascript for adding inline fields doesn't update "for" attribute in label

[Django]

#13674: Javascript for adding inline fields doesn't update "for" attribute in 
label
---+
  Reporter:  Jonas | Owner:  rctay
Status:  new   | Milestone:  1.3  
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:|  Keywords:  admin
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by rctay):

  * owner:  nobody => rctay

-- 
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] #12213: Initial data and addition queryset_filter for formset from inlineformset_factory

[Django]

#12213: Initial data and addition queryset_filter for formset from
inlineformset_factory
-+--
  Reporter:  ramusus | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Forms   |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  1 
Needs_better_patch:  0   |  
-+--
Comment (by sehmasch...@gmail.com):

 btw: the above patch works great. any reason for not adding this patch?

-- 
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] #13674: Javascript for adding inline fields doesn't update "for" attribute in label

[Django]

#13674: Javascript for adding inline fields doesn't update "for" attribute in 
label
---+
  Reporter:  Jonas | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:  admin 
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by rctay):

 Attached a patch for both the full and minified JS files.

 Note that apart from changing the regex to search for {{{__prefix___}}}
 instead of a number ({{{\d+}}}), the capturing parentheses {{{()}}} has
 also been removed, since we don't need the matched result.

-- 
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] #13674: Javascript for adding inline fields doesn't update "for" attribute in label

[Django]

#13674: Javascript for adding inline fields doesn't update "for" attribute in 
label
---+
  Reporter:  Jonas | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:  admin 
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by rctay):

 Replying to [ticket:13674 Jonas]:
 > This is the patch that solved it for me:
 >
 > {{{
 > diff --git a/django/contrib/admin/media/js/inlines.js
 b/django/contrib/admin/media/js/inlines.js
 > index cf79023..90b50b5 100644
 > --- a/django/contrib/admin/media/js/inlines.js
 > +++ b/django/contrib/admin/media/js/inlines.js
 > @@ -75,6 +75,14 @@
 > }).each(function() {
 > var el = $(this);
 > el.attr("name",
 el.attr("name").replace(/__prefix__/g, nextIndex));
 > +   })
 > +   .end()
 > +   .filter(function() {
 > +   var el = $(this);
 > +   return el.attr("for") &&
 el.attr("for").search(/__prefix__/) >= 0;
 > +   }).each(function() {
 > +   var el = $(this);
 > +   el.attr("for",
 el.attr("for").replace(/__prefix__/g, nextIndex));
 > });
 > if (row.is("tr")) {
 > // If the forms are laid out in
 table rows, insert
 > }}}

 You should be modifying {{{updateElementIndex()}}} instead - it will be
 much cleaner.

 {{{
 diff --git a/django/contrib/admin/media/js/inlines.js
 b/django/contrib/admin/media/js/inlines.js
 index cf79023..21e00ad 100644
 --- a/django/contrib/admin/media/js/inlines.js
 +++ b/django/contrib/admin/media/js/inlines.js
 @@ -18,7 +18,7 @@
 $.fn.formset = function(opts) {
 var options = $.extend({}, $.fn.formset.defaults, opts);
 var updateElementIndex = function(el, prefix, ndx) {
 -   var id_regex = new RegExp("(" + prefix +
 "-\\d+)");
 +   var id_regex = new RegExp(prefix + "-__prefix__");
 var replacement = prefix + "-" + ndx;
 if ($(el).attr("for")) {
 $(el).attr("for",
 $(el).attr("for").replace(id_regex, replacement));
 }}}

-- 
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] #12213: Initial data and addition queryset_filter for formset from inlineformset_factory

[Django]

#12213: Initial data and addition queryset_filter for formset from
inlineformset_factory
-+--
  Reporter:  ramusus | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Forms   |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  1 
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

 * cc: sehmasch...@gmail.com (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-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] #12213: Initial data and addition queryset_filter for formset from inlineformset_factory

[Django]

#12213: Initial data and addition queryset_filter for formset from
inlineformset_factory
-+--
  Reporter:  ramusus | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Forms   |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  1 
Needs_better_patch:  0   |  
-+--
Changes (by sehmasch...@gmail.com):

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

Comment:

 reopening this for the following reasons:
 – no docs. how is queryset supposed to work like initial-data? any
 examples? I´ve tried this for days without any luck.
 – why use queryset in the first place when using initial-data is more
 coherent?

-- 
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] #13591: SplitDateTimeField admin usability broken when using format localization

[Django]

#13591: SplitDateTimeField admin usability broken when using format localization
---+
  Reporter:  ludwik| Owner:  nobody 

Status:  new   | Milestone:  1.3

 Component:  Forms |   Version:  1.2

Resolution:|  Keywords:  localization, 
SplitDateTimeField, admin
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by andybak):

 * cc: a...@andybak.net (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-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] #11003: Add USE INDEX, FORCE INDEX capabilities to ORM

[Django]

#11003: Add USE INDEX, FORCE INDEX capabilities to ORM
---+
  Reporter:  Renato Alves  | Owner:  nobody 

Status:  closed| Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:  wontfix   |  Keywords:  INDEX USE 
FORCE
 Stage:  Design decision needed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

Needs_better_patch:  0 |  
---+
Changes (by lrekucki):

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

Comment:

 Please do not reopen tickets marked as `won't fix` by core developers (I'm
 not a one), without prior discussion on [http://groups.google.com/group
 /django-developers django-developers]. Send your proposal there and if
 consensus is reached, the ticked will be 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] #11003: Add USE INDEX, FORCE INDEX capabilities to ORM

[Django]

#11003: Add USE INDEX, FORCE INDEX capabilities to ORM
---+
  Reporter:  Renato Alves  | Owner:  nobody 

Status:  reopened  | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  INDEX USE 
FORCE
 Stage:  Design decision needed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

Needs_better_patch:  0 |  
---+
Changes (by simon29):

 * cc: rkm, simon29 (added)
  * status:  closed => reopened
  * has_patch:  0 => 1
  * resolution:  wontfix =>
  * needs_tests:  0 => 1

Comment:

 Here's a suggestion. See patch. Works on MySQL.

 {{{
 Model.objects.filter(field=value).with_hints('my_index')
 Model.objects.filter(field__fk1__fk2=value).with_hints('my_index',
 RelatedModel1='index1', RelatedModel2='index2')
 }}}

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