Re: Please Apply #5801 - GET parameters are ignored in redirect for Admin

2008-07-19 Thread Rozza

Yeah looks like it except #5775 just focuses on the decorator and
#5801 focuses on all admin logins (the original patch just looked at
the decorator though).

The new patch for #5801 focuses both on the decorated custom admin
views and normal admin views.  It also normalises the behaviour
between the decorator logic and the sites.py login method as they
behaved differently.

Ross

On Jul 18, 11:07 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> Errr, isn't that a duplicate of 
> #5775?http://code.djangoproject.com/ticket/5775
>
> On Jul 19, 6:19 am, Rozza <[EMAIL PROTECTED]> wrote:
>
> > New patch with tests added to the ticket.
>
> > Shows the reason for the triage process!
>
> > All the best
>
> > Ross
>
> > On Jul 18, 2:54 pm, Rozza <[EMAIL PROTECTED]> wrote:
>
> > > Thanks Russell,
>
> > > I write the tests and attach to the ticket asap.
>
> > > Ross
>
> > > On Jul 18, 2:01 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > On Fri, Jul 18, 2008 at 8:47 PM, Rozza <[EMAIL PROTECTED]> wrote:
>
> > > > > Ah no problems!
>
> > > > > As there aren't any tests for the staff_member_required or even
> > > > > request.get_full_path() I wasn't 100% sure what the procedure would be
> > > > > as these are used through out Django.
>
> > > > > As it's such a minor change does it warrant the bureaucracy of
> > > > > requiring tests to have it implemented?
>
> > > > Yes. Next question? :-)
>
> > > > There are some parts of Django that either do not have tests. These
> > > > usually correspond to the oldest parts of the framework, which existed
> > > > before Django had a full testing framework. Tha'ts not an excuse to
> > > > avoid writing tests - it just means that your tests will be the first
> > > > tests in that area.
>
> > > > The tests serve multiple purposes:
> > > >  - they demonstrate the existence of a problem, which makes the triage
> > > > process easier
> > > >  - they demonstrate that your patch fixes the problem
> > > >  - they prevent the problem from happening again in the future.
>
> > > > With very few exceptions, nothing gets committed to the code base
> > > > unless it has tests.
>
> > > > > I think definitely there  should be a ticket opened to ensure that
> > > > > tests are written to test the logic staff_member_required and
> > > > > request.get_full_path().  At the moment I'm not sure where they would
> > > > > fit.
>
> > > > The hard part is writing the tests, not deciding where to put them.
> > > > Worst case, the core developer that commits your patch will put the
> > > > tests into a different location.
>
> > > > However, that said, the decision on where to put a test goes something
> > > > like this:
> > > >  * Is it a specific test of a contrib app? If yes, put it in the tests
> > > > module for that app
> > > >  * Could the test serve as a form of documentation for a feature? If
> > > > yes, put it in modeltests.
> > > >  * Otherwise, put it in regressiontests.
>
> > > > Beyond that, try to add the tests to an existing test module within
> > > > modeltests/regressiontests; however, if you can't find anything
> > > > appropriate, feel free to suggest a new test module.
>
> > > > Yours,
> > > > Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Use admin.autodiscover() by default?

2008-07-19 Thread James Bennett

As of the newforms-admin merge, the IRC channel is seeing a sudden
rush of folks who try the tutorial and complain because the admin
doesn't work. And they're right, because as written the tutorial sets
up the admin in such a way that it's never aware of any models being
registered -- including the contrib models that already have admin
classes.

Adding 'admin.autodiscover()' to the project's root URLConf fixes
this; normally I'd just check in a quick change to the tutorial to
indicate that this should happen, but it feels to me like the right
thing to do here is instead tweak the project template so that line is
in the default URLConf (but commented out like the rest of the admin
stuff), at which point the tutorial can simply stay as-is.

Thoughts?


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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



Re: #7611 contrib.auth PasswordResetTest requires specific templates for tests to pass

2008-07-19 Thread Jason Yan

I attached a new patch to the ticket in the original post.  The hard-
coded URL felt like it went against your reasoning for testing the
auth application in your own project, so hopefully this approach gives
us the best of both worlds.  Without a proper way to skip test cases
yet, I decided to follow what other tests did and pass the test in the
case where the test is actually skipped.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Use admin.autodiscover() by default?

2008-07-19 Thread Valts Mazurs
+1 As this would remove unneccessary frustration.

Regards,
Valts.

On Sat, Jul 19, 2008 at 11:08 AM, James Bennett <[EMAIL PROTECTED]>
wrote:

>
> As of the newforms-admin merge, the IRC channel is seeing a sudden
> rush of folks who try the tutorial and complain because the admin
> doesn't work. And they're right, because as written the tutorial sets
> up the admin in such a way that it's never aware of any models being
> registered -- including the contrib models that already have admin
> classes.
>
> Adding 'admin.autodiscover()' to the project's root URLConf fixes
> this; normally I'd just check in a quick change to the tutorial to
> indicate that this should happen, but it feels to me like the right
> thing to do here is instead tweak the project template so that line is
> in the default URLConf (but commented out like the rest of the admin
> stuff), at which point the tutorial can simply stay as-is.
>
> Thoughts?
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> >
>

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



Re: Django on Python 2.6

2008-07-19 Thread Jacob Kaplan-Moss

Hey Karen --

Thanks for looking into this. I don't have the bandwidth to think
about it right now, but we should make sure that Django 1.0 final
works with Python 2.6. Let's make this a target for the 1.0 beta2
release?

Jacob

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



Re: Use admin.autodiscover() by default?

2008-07-19 Thread Russell Keith-Magee

On Sat, Jul 19, 2008 at 4:08 PM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> Adding 'admin.autodiscover()' to the project's root URLConf fixes
> this; normally I'd just check in a quick change to the tutorial to
> indicate that this should happen, but it feels to me like the right
> thing to do here is instead tweak the project template so that line is
> in the default URLConf (but commented out like the rest of the admin
> stuff), at which point the tutorial can simply stay as-is.

I agree that this is something that should be in the project template.
However, we can't completely avoid changes to the tutorial text - the
text about what needs to be uncommented will need to be tweaked
slightly. A quick explanation in tutorial 3 of the purpose of the
admin.autodiscover() would also be appropriate, IMHO.

Russ %-)

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



Re: Use admin.autodiscover() by default?

2008-07-19 Thread Jacob Kaplan-Moss

On Sat, Jul 19, 2008 at 3:08 AM, James Bennett <[EMAIL PROTECTED]> wrote:
> Adding 'admin.autodiscover()' to the project's root URLConf fixes
> this; normally I'd just check in a quick change to the tutorial to
> indicate that this should happen, but it feels to me like the right
> thing to do here is instead tweak the project template so that line is
> in the default URLConf (but commented out like the rest of the admin
> stuff), at which point the tutorial can simply stay as-is.

We should do both -- many of these questions (especially early on) are
going to be from people who're upgrading instead of starting anew (the
dynamic might shift after 1.0 final).

Jacob

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



Re: Use admin.autodiscover() by default?

2008-07-19 Thread Brian Rosner


On Jul 19, 2008, at 2:08 AM, James Bennett wrote:

> Adding 'admin.autodiscover()' to the project's root URLConf fixes
> this; normally I'd just check in a quick change to the tutorial to
> indicate that this should happen, but it feels to me like the right
> thing to do here is instead tweak the project template so that line is
> in the default URLConf (but commented out like the rest of the admin
> stuff), at which point the tutorial can simply stay as-is.
>
> Thoughts?

Yeah, I agree that this should be done. I originally took the stance  
that it might be an uncommon thing since most people might want a  
custom AdminSite instance, and boy was I wrong ;)

Tweaking the tutorial would be a good idea too. Give a bit of  
information about it would be a good thing.

Brian Rosner
http://oebfare.com

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



Re: Use admin.autodiscover() by default?

2008-07-19 Thread Karen Tracey
On Sat, Jul 19, 2008 at 8:45 AM, Jacob Kaplan-Moss <
[EMAIL PROTECTED]> wrote:

>
> On Sat, Jul 19, 2008 at 3:08 AM, James Bennett <[EMAIL PROTECTED]>
> wrote:
> > Adding 'admin.autodiscover()' to the project's root URLConf fixes
> > this; normally I'd just check in a quick change to the tutorial to
> > indicate that this should happen, but it feels to me like the right
> > thing to do here is instead tweak the project template so that line is
> > in the default URLConf (but commented out like the rest of the admin
> > stuff), at which point the tutorial can simply stay as-is.
>
> We should do both -- many of these questions (especially early on) are
> going to be from people who're upgrading instead of starting anew (the
> dynamic might shift after 1.0 final).
>
>
FYI there was a ticket opened last night that suggests both of these:

http://code.djangoproject.com/ticket/7824

Karen

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



Re: Please Apply #5801 - GET parameters are ignored in redirect for Admin

2008-07-19 Thread Julien Phalip

Errr, isn't that a duplicate of #5775?
http://code.djangoproject.com/ticket/5775

On Jul 19, 6:19 am, Rozza <[EMAIL PROTECTED]> wrote:
> New patch with tests added to the ticket.
>
> Shows the reason for the triage process!
>
> All the best
>
> Ross
>
> On Jul 18, 2:54 pm, Rozza <[EMAIL PROTECTED]> wrote:
>
> > Thanks Russell,
>
> > I write the tests and attach to the ticket asap.
>
> > Ross
>
> > On Jul 18, 2:01 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Fri, Jul 18, 2008 at 8:47 PM, Rozza <[EMAIL PROTECTED]> wrote:
>
> > > > Ah no problems!
>
> > > > As there aren't any tests for the staff_member_required or even
> > > > request.get_full_path() I wasn't 100% sure what the procedure would be
> > > > as these are used through out Django.
>
> > > > As it's such a minor change does it warrant the bureaucracy of
> > > > requiring tests to have it implemented?
>
> > > Yes. Next question? :-)
>
> > > There are some parts of Django that either do not have tests. These
> > > usually correspond to the oldest parts of the framework, which existed
> > > before Django had a full testing framework. Tha'ts not an excuse to
> > > avoid writing tests - it just means that your tests will be the first
> > > tests in that area.
>
> > > The tests serve multiple purposes:
> > >  - they demonstrate the existence of a problem, which makes the triage
> > > process easier
> > >  - they demonstrate that your patch fixes the problem
> > >  - they prevent the problem from happening again in the future.
>
> > > With very few exceptions, nothing gets committed to the code base
> > > unless it has tests.
>
> > > > I think definitely there  should be a ticket opened to ensure that
> > > > tests are written to test the logic staff_member_required and
> > > > request.get_full_path().  At the moment I'm not sure where they would
> > > > fit.
>
> > > The hard part is writing the tests, not deciding where to put them.
> > > Worst case, the core developer that commits your patch will put the
> > > tests into a different location.
>
> > > However, that said, the decision on where to put a test goes something
> > > like this:
> > >  * Is it a specific test of a contrib app? If yes, put it in the tests
> > > module for that app
> > >  * Could the test serve as a form of documentation for a feature? If
> > > yes, put it in modeltests.
> > >  * Otherwise, put it in regressiontests.
>
> > > Beyond that, try to add the tests to an existing test module within
> > > modeltests/regressiontests; however, if you can't find anything
> > > appropriate, feel free to suggest a new test module.
>
> > > Yours,
> > > Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Doc Refactor

2008-07-19 Thread Jeff Anderson

Hello,

I'm curious about the status of the documentation refactor.

I see that it is on the 'maybe' list, and that the hg repo hasn't been 
touched in a couple months.


What's the best way to get up to speed and help get this ready for checkin?

Thanks!


Jeff Anderson



signature.asc
Description: OpenPGP digital signature


Closing nfa-fixed tickets?

2008-07-19 Thread Karen Tracey
Now that newforms-admin is merged, tickets tagged with nfa-fixed ought to be
closed as fixed, right?  Does that need to be done manually or will
something automagic be run that does it?  (It doesn't appear that there are
all that many out there, so it could be done manually if that's easiest.)

Karen

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



Re: Closing nfa-fixed tickets?

2008-07-19 Thread Malcolm Tredinnick


On Sat, 2008-07-19 at 17:09 -0400, Karen Tracey wrote:
> Now that newforms-admin is merged, tickets tagged with nfa-fixed ought
> to be closed as fixed, right?  Does that need to be done manually or
> will something automagic be run that does it?  (It doesn't appear that
> there are all that many out there, so it could be done manually if
> that's easiest.)

They'll have to be done manually. But I just pinged Brian on IRC and he
was going to go through and check that stuff (and some others). So I'll
leave it in his capable hands.

Regards,
Malcolm




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



Re: DjangoCon

2008-07-19 Thread Frijole

that's what I'm worried about

On Jul 18, 4:10 pm, Matt <[EMAIL PROTECTED]> wrote:
> On Jul 18, 1:21 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
>
> > When the time comes there will be a large and loud public announcement
> > that you will not be able to miss.
>
> Somehow when those large and loud public announcements happen I seem
> to get them about 10 minutes after everyone else.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Is URL template tag's syntax going to change?

2008-07-19 Thread Julien Phalip

Hi,

For months, there has been a mention in the url tag's documentation:

"Note that the syntax for this tag may change in the future, as we
make it more robust." [1]

Is that mention still relevant for 1.0 and beyond?

Julien

[1] http://www.djangoproject.com/documentation/templates/#url
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Ticket: 6396 - Move HTML tags into change_list_results.html

2008-07-19 Thread Martin Diers
http://code.djangoproject.com/ticket/6396

I just updated this ticket with a patch which moves the generation of  
html out of admin.templatetags.admin_list.items_for_result  and into  
change_list_results.html.

I needed this functionality in order to change the Name column to  
include indentation which represents a tree structure. At present, the  
entire row (between the  tags) is generated in code, making it  
nearly impossible to override. In my patch, the items_for_result  
function returns a list of dictionaries, and assembles the various  
pieces in the change_list_results.html template, which is included  
using the result_list tag, in change_list.html.

The existing patch on this ticket eliminated the result_list tag  
entirely, moving row generation into change_list.html. My patch is  
much more simple - changing only a few lines of code, and retaining  
the result_list tag.

How would one use this? You can override change_list.html, replacing  
the result_list tag with your custom version of the result_list  
include tag which has any needed customizations. For example, you can  
add a column containing tools, to a specific model's change list.

Also, since the merge has happened, I changed the ticket from newforms- 
admin to SVN.

I have not created tests, as I am uncertain how to go about it when  
templates are involved. Any pointers would be appreciated.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Closing nfa-fixed tickets?

2008-07-19 Thread Jacob Kaplan-Moss

On Sat, Jul 19, 2008 at 2:42 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> They'll have to be done manually. But I just pinged Brian on IRC and he
> was going to go through and check that stuff (and some others). So I'll
> leave it in his capable hands.

I can automatically do it today through the magic of SQL... if that's
what y'all want. Just lemee know.

Jacob

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