On Tue, Apr 24, 2012 at 17:30, Tai Lee wrote:
> This seems odd to me. [...]
> I don't remember a thread started by Django core letting the community know
> that a move was seriously on the cards, and giving the community a chance to
> have some formal input before a decision was made.
>[...]
> On
On Sat, Mar 17, 2012 at 20:38, Aymeric Augustin
wrote:
>[...]
> Besides, I find project-wide "user profiles" impractical for most purposes. I
> prefer subclassing auth.User even if I just need a few extra fields, and add
> enough glue (middleware, auth backend, login and logout views) to hold th
On Thu, Mar 15, 2012 at 22:53, Danny Adair wrote:
>[...]
> I'd like to see a later, "proper" auth.user that can undo that chaos.
I originally thought you intended a setting which let's the user
switch from the existing auth to an email auth with corresponding User
mod
On Mon, Mar 12, 2012 at 16:57, Clay McClure wrote:
>[...]
> New django projects can elect to use an entirely different pluggable auth
>[...]
> The pluggable-auth-apps fork is barely two days old, so it's still rough
> around the edges, and I've almost certainly missed some things. I haven't
>[...]
On Fri, Mar 9, 2012 at 21:13, Florian Apolloner wrote:
>[...]
> Yes, since no one needs it. Okay no one isn't true, but no one (for true
> this time) who needed it stepped up and said "I'll implement it and see that
> it ends up in trunk"
It's the "required" of username that's the problem if you
On Fri, Mar 9, 2012 at 20:01, Donald Stufft wrote:
> The major issue is that there is no way to do schema migrations in core
> (currently). So there's no way to handle increasing the length of the
> username field.
I don't understand what the "username" field length has to do with it.
And I thin
On Tue, Mar 6, 2012 at 12:21, Martin Ostrovsky
wrote:
> Danny reading your reply gave me an idea to try and it worked.
>
> I switched the order of the inlines. So I put C first, then B. This way C
> validates properly, then B is deleted and the cascaded deletion deletes C
> and everything works as
On Tue, Mar 6, 2012 at 12:06, Martin Ostrovsky
wrote:
>[...]
> Now I get what's happening (I think), B gets deleted first, then the formset
> validation for C runs, tries to validate the drop down choice, and fails
> since B has already been deleted.
>
> What do you guys think? Is this a bug or a
On Tue, Feb 21, 2012 at 21:00, Anssi Kääriäinen wrote:
>[...]
> The real problem is, as said before, that whatever you do, last edited
> date doesn't work in multi-timezone setting. Somebody is going to see
> last edited "tomorrow" or seeing his last edit as "yesterday".
I agree, "last edited" as
On Tue, Feb 21, 2012 at 14:17, Yo-Yo Ma wrote:
>[...]
> When using UTC, which, if any, are true:
Not sure what you mean by "using UTC", I assume you mean "USE_TZ = True".
As per first sentence of
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/
"When support for time zones is enabled,
On Tue, Feb 21, 2012 at 13:17, Yo-Yo Ma wrote:
> I haven't quite read up on all the UTC-related stuff in Django as of
> yet (couldn't find much info about it), but I found some of the posts
> above concerning. It would seem that if a DateTimeField should be
> updated with ``timezone.now()``, then
On Tue, Feb 21, 2012 at 10:48, Anssi Kääriäinen wrote:
>[...]
> Current documentation doesn't help here.
I agree that a "Timezones FAQ" should mention
DateField(auto_now=True), with a reference from there also back to the
FAQ.
Really the complication are the timezones themselves, not the
mechani
On Tue, Feb 21, 2012 at 09:29, Anssi Kääriäinen wrote:
>[...]
>> This is by design. Timezones don't make sense for date or times, only for
>> datetimes.
>
> In [15]: activate('Australia/Sydney')
> In [16]: localtime(now()).date()
> Out[16]: datetime.date(2012, 2, 21)
> In [17]: activate('Europe/H
Thanks Aymeric,
On Sat, Jan 28, 2012 at 09:49, Aymeric Augustin
wrote:
>[...]
> Currently, there's no built-in UI for timezone selection. However, I've
> described some ideas, along with sample code, in the documentation:
> https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#selecting-t
On Sun, Jan 29, 2012 at 04:13, Daniel Greenfeld wrote:
>[...]
>> The original reason -- that the admin isn't intended as a general
>> purpose site, just a backend editing interface -- is still valid. I'm
>> not in favor of trying to turn the admin into something that people
>> will try to interpre
15 matches
Mail list logo
