Re: Ticket #5373

2010-07-10 Thread Lachlan Musicman
On Fri, Jul 9, 2010 at 00:00, Russell Keith-Magee wrote: > On Thu, Jul 8, 2010 at 3:55 PM, Lachlan Musicman wrote: >> Hola, >> >> I'm new to this dev thing, but I've done some work on ticket #5373 > > Thanks for pitching in! Hopefully I'll be able to give you enough > feedback to progress this is

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

2010-07-10 Thread Alex Gaynor
On Sat, Jul 10, 2010 at 7:24 AM, Russell Keith-Magee wrote: > On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer wrote: >> On Jul 7, 7:11 pm, Graham Dumpleton >> wrote: >> [snip] >>> web application, to be a well behaved WSGI citizen, should honour >>> SCRIPT_NAME setting as supplied by the server, an

Re: natural keys and dumpdata

2010-07-10 Thread Simon Meers
> I'll put it on my todo list; if anyone else wants to give it a sanity > check, I'd appreciate the extra eyeballs. Looks pretty sane to me, though I wonder if the deserialisation should raise an exception if the pk is missing and an incomplete set of natural key fields is provided? Nice work, tha

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

2010-07-10 Thread Russell Keith-Magee
On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer wrote: > On Jul 7, 7:11 pm, Graham Dumpleton > wrote: > [snip] >> web application, to be a well behaved WSGI citizen, should honour >> SCRIPT_NAME setting as supplied by the server, and ensure that ways >> are provided such that everything in the users

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

2010-07-10 Thread Russell Keith-Magee
On Sat, Jul 10, 2010 at 12:19 AM, burc...@gmail.com wrote: > Tom, > > HTTP_HOST and other don't solve the multiple-host deployment, and it > is a solution you can do by yourself if you need. > > I'd like to see better solution: ability to make reverse work for such URLs. > I think, currently the p

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

2010-07-10 Thread Russell Keith-Magee
On Fri, Jul 9, 2010 at 6:47 PM, Tom Evans wrote: > On Thu, Jul 8, 2010 at 3:40 PM, Russell Keith-Magee > wrote: >> Personally, I see this as a case of explicit vs implicit. >> >> As currently defined, LOGIN_URL points to the login URL. Period. >> >> Under the proposed patch, the onus is on every

Re: natural keys and dumpdata

2010-07-10 Thread Stijn Hoop
Hello, On Jul 9, 9:13 pm, SmileyChris wrote: > It seems that my ticket in http://code.djangoproject.com/ticket/13252 > covers this. It's ready for review if anyone wants to give it a > spin... That patch indeed matches mine, but yours is of course much further along. Javier Guerra Giraldez wrot

Re: Regression problem on admin date format

2010-07-10 Thread Antoni Aloy
2010/7/10 Russell Keith-Magee : > On Sat, Jul 10, 2010 at 1:15 AM, Antoni Aloy wrote: > Are you sure that this is a regression, rather than a bugfix with > unfortunate side effects? In particular, I draw your attention to the > second note under: > > http://docs.djangoproject.com/en/1.2/topics/i1

Re: Enhanced URL Resolver Match

2010-07-10 Thread Russell Keith-Magee
On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite wrote: > When Django 1.1 was released URLs gained the ability to be nested with > namespaces by adding "app_name" and "namespace" attributes to the > include(...) functions within urls.py. The reverse(...) function was > updated to allow you to specify

Re: Django Model Related Manager Enhancements

2010-07-10 Thread Russell Keith-Magee
On Thu, Jul 8, 2010 at 10:45 PM, Nowell Strite wrote: > Recently I started working on a project (django-versions) to enable > versioning of model data with Mercurial. In doing so, I came across > the need to have access to more data about the relationships that > Django Related Manager's create. F

Re: Regression problem on admin date format

2010-07-10 Thread Russell Keith-Magee
On Sat, Jul 10, 2010 at 1:15 AM, Antoni Aloy wrote: > Hello, > > Have anybody (Marc Garcia ?) check > http://code.djangoproject.com/ticket/13621 ticket. It explains a bug > concerning date and time formats. The admin does not conform the i18n > locale settings on displaying time and date formats a