[Django] #10009: Wrong variable name in example (page "Working with forms")

[Django]

#10009: Wrong variable name in example (page "Working with forms")
---+
 Reporter:  kari...@gmail.com  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In the "Working with forms"
 (http://docs.djangoproject.com/en/dev/topics/forms/) page the third
 example from the bottom has a wrong variable in one place.  The relevant
 code in the example is:

 {{{
 {% if forloop.first %}
 {% for hidden in form.hidden_fields %}
 {{ field }}
 {% endfor %}
 {% endif %}
 }}}

 Instead of {{ field }} it should read {{ hidden }} (unless I am much
 mistaken).

 Thanks for all your hard work!

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

Re: [Django] #10008: JSON Serializer throwing tracebacks

[Django]

#10008: JSON Serializer throwing tracebacks
+---
  Reporter:  erikcw | Owner:  nobody
Status:  closed | Milestone:
 Component:  Serialization  |   Version:  SVN   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kratorius):

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

Comment:

 Duplicate of #10006.

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

Re: [Django] #9496: reverse() function doesn't seem to take account of the includer urlconf

[Django]

#9496: reverse() function doesn't seem to take account of the includer urlconf
+---
  Reporter:  seemant| Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by seemant):

 For some reason, I don't get emailed on updates, so I didn't see the
 comments till just now.  I'm so sorry for the latency.  I will put my
 examples up here in just a few minutes

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

Re: [Django] #10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()

[Django]

#10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()
-+--
  Reporter:  Jon | Owner:  nobody  
Status:  closed  | Milestone:  post-1.0
 Component:  Forms   |   Version:  
Resolution:  invalid |  Keywords:  modelform_factory assumption
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by kmtracey):

 Replying to [comment:5 Jon]:
 > kmtracey - any chance of removing email address from audit note above?
 > thanks
 Sorry, I don't have any way to do that.

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

Re: [Django] #9958: Split contrib.comments CommentForm class to allow easier customization

[Django]

#9958: Split contrib.comments CommentForm class to allow easier customization
--+-
  Reporter:  arne | Owner:  nobody  
   
Status:  new  | Milestone:  
   
 Component:  django.contrib.comments  |   Version:  SVN 
   
Resolution:   |  Keywords:  comments, 
customization
 Stage:  Design decision needed   | Has_patch:  0   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by thejaswi_puthraya):

 Ok here is what is basically done. First there is a BaseCommentForm that
 holds the most vital fields of the form ie content_type, object_pk,
 timestamp and security hash. Then a second form called MetaCommentForm
 (that is a subclass of BaseCommentForm)(please change the name of
 MetaCommentForm if it sounds confusing) that holds the name, email, url
 etc fields. Then a third form called CommentForm (a subclass of
 MetaCommentForm) that holds the honeypot.

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

Re: [Django] #9958: Split contrib.comments CommentForm class to allow easier customization

[Django]

#9958: Split contrib.comments CommentForm class to allow easier customization
--+-
  Reporter:  arne | Owner:  nobody  
   
Status:  new  | Milestone:  
   
 Component:  django.contrib.comments  |   Version:  SVN 
   
Resolution:   |  Keywords:  comments, 
customization
 Stage:  Design decision needed   | Has_patch:  0   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by thejaswi_puthraya):

 Replying to [comment:3 arne]:
 > Using 9958.diff solves a different problem than my original patch
 comments.diff. With the approach in 9958.diff neither inheriting from
 !BaseCommentForm nor inheriting from !CommentForm allows for easy
 customization of the fields the form uses.
 >
 > Please consider that not every projects needs a comment form with the
 fields "name", "email", "url" and "comment". Sometimes "name" and
 "comment" may be enough and 9958.diff gives no form-class from which I can
 inherit to cleanly build my own comment form with less fields than the
 original !CommentForm. I feel like overriding !__init!__() and using del
 to delete form-fields is not a clean solution.
 >

 Thank you for providing an insight into your problem.

 > Using an approach like in comments.diff one can either subclass
 !BaseCommentForm to customize the fields the form has and use all the
 existing Spam-protection logic or could use a completly other form
 (inheriting form forms.Form) to circumvent the Spam-protection as
 thejaswi_puthraya pointed out and the ability to customize the fields.

 I have seen a lot of requests in IRC from people who felt that the current
 honeypot mechanism provided by the comments was insufficient and/or was
 redundant with their home-grown/third-party solution. Hence I segregated
 the two forms to remove that redundancy.

 Here are my observations regarding your patch:
 * I would prefer your patch provided it does not have the honeypot in the
 BaseCommentForm because it forces the spam protection on users who don't
 require one.
 * It still does not remove the pain of say having a form that removes the
 email field and I am sure no other patch can remove that pain. It is best
 to draw a line somewhere and let the user take a small pain (one-time
 effort) to write a custom form.

 My personal opinion is that spam protection should be optional. Let me
 come up with another patch that tackles mixes both your problem and mine.

 Let's leave it to the devels and see what is the best for such a scenario.

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

Re: [Django] #8138: Switch django tests to use transactions

[Django]

#8138: Switch django tests to use transactions
+---
  Reporter:  mremolt| Owner:  nobody  
Status:  new| Milestone:  post-1.0
 Component:  Testing framework  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by ericholscher):

 It appears that Ellington has a custom test runner for doc tests
 (basically the patch from #5624). I missed this earlier (and that explains
 why there was no difference between the above patches in my reply before
 this).

 We are currently doing a flush and then a loaddata on fixtures found in
 doctests. We are loading fixtures in the doc tests, and not cleaning them
 up (until next time around when a flush occurs it seems.) I believe that a
 unit test is being run in between all of these instances, probably rolling
 back the transaction at the end (as I understand it, my database knowledge
 is lacking), which is allowing the rest of the tests to pass.

 The good news is that I now have the entire ellington suite passing with
 the above behavior (with 11x speed increase). We had a couple instances of
 tests relying on a previous test's data sticking around, and one instance
 of a test depending on the pk of it's contents to pass. Fixing those up
 allowed me to make all of the test suite pass.

 Taking out the flushing threw things through a loop. With the tzcommit
 patch, I was getting some collision of slug fields. This was caused by
 incomplete fixtures that didn't have a slug, and used to work because
 there wasn't another thing of that value being set in that test. These are
 now fixed.

 I think that it will be possible to get the full suite running on the
 patch that does doctest transaction rollbacks. However, since we are
 loading fixtures outside of the doctest runner currently, I am getting
 some bleed over on tests. I'm assuming this is because the loaddata is
 happening before the call to the DoctestRunner. If we put this fixture
 loading logic there, inside the transaction, I think all tests would now
 pass. I think the fact that we're using fixtures in doctests basically
 makes it so that we have to run a custom test runner (unless #5624 gets
 accepted, where transactions would almost be necessary around doctests...
 This would solve the inconsistency, and give a reason to have rollbacks on
 doctests.)

 An interesting benchmark; the test suite when I take out the flush took
 around 180s to run. (This is almost around a real 30x speed increase, and
 3x faster than with the flush.). Unit tests seem to gain even more
 performance from transactions because the database was being flushed
 before every test (IIRC).

 Sorry about the false report before, and let me know if there's anything
 else I can do. I'll spend some time tomorrow trying to get our suite
 passing without flushing of the DB, probably by moving out fixture loading
 inside the transaction in doctests.

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

Re: [Django] #9958: Split contrib.comments CommentForm class to allow easier customization

[Django]

#9958: Split contrib.comments CommentForm class to allow easier customization
--+-
  Reporter:  arne | Owner:  nobody  
   
Status:  new  | Milestone:  
   
 Component:  django.contrib.comments  |   Version:  SVN 
   
Resolution:   |  Keywords:  comments, 
customization
 Stage:  Design decision needed   | Has_patch:  0   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by arne):

 Using 9958.diff solves a different problem than my original patch
 comments.diff. With the approach in 9958.diff neither inheriting from
 !BaseCommentForm nor inheriting from !CommentForm allows for easy
 customization of the fields the form uses.

 Please consider that not every projects needs a comment form with the
 fields "name", "email", "url" and "comment". Sometimes "name" and
 "comment" may be enough and 9958.diff gives no form-class from which I can
 inherit to cleanly build my own comment form with less fields than the
 original !CommentForm. I feel like overriding !__init!__() and using del
 to delete form-fields is not a clean solution.

 Using an approach like in comments.diff one can either subclass
 !BaseCommentForm to customize the fields the form has and use all the
 existing Spam-protection logic or could use a completly other form
 (inheriting form forms.Form) to circumvent the Spam-protection as
 thejaswi_puthraya pointed out and the ability to customize the fields.

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

Re: [Django] #10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()

[Django]

#10005: Incorrect classname assumed in ModelFormMetaClass modelform_factory()
-+--
  Reporter:  Jon | Owner:  nobody  
Status:  closed  | Milestone:  post-1.0
 Component:  Forms   |   Version:  
Resolution:  invalid |  Keywords:  modelform_factory assumption
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by Jon):

 Thank you! (doh!)

 kmtracey - any chance of removing email address from audit note above?
 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9887: Testclient user have not enough permissions to create another users.

[Django]

#9887: Testclient user have not enough permissions to create another users.
--+-
  Reporter:  nuald   | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Testing framework|   Version:  1.0   
Resolution:  wontfix  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by ubernostrum):

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

Comment:

 Replying to [comment:3 nuald ]:
 >  - automated admin sites in Django is not flexible enough - we can't
 allow user to modify only its own account without access to other
 accounts;

 You most certainly can set that up, by unregstering the default
 `ModelAdmin` for the `User` class, then registering your own with an
 overridden `has_change_permission` that implements your custom logic.

 At any rate, this seems like a case where your specific needs will require
 you to come up with specific workarounds rather than ask Django to work
 around things for you.

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