Re: Feature request: read-only admin view
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 interpret as a publicly visible CMS. > > I agree 100%. The admin should remain the admin. I look at the admin as "just another app" which provides a CRUD interface and happens to have lots of hooks and templates for customization. There are use cases without a backend/public differentiation - sometimes all you want is CRUD. There are numerous examples of models you want to be able to "C", "R" and "D" but not "U". Currently, there are three permissions - for "C", "U" and "D" - and the app respects these and adjusts the interface accordingly. Certain admin users may not be able to create or delete certain models. I don't see how "completing" this by adding a permission for "R" and adjusting the interface accordingly would make the admin something it isn't (or isn't "supposed to be"). I believe the advent of "ModelAdmin.readonly_fields" is a confirmation of this need. "R" and "U" are currently mixed together - there are reasons for why this is the case but I don't see the historic explanations holding up as reasons to leave it like that. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: "Current" timezone in admin
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-the-current-time-zone > > There's also a sample app here: https://bitbucket.org/aaugustin/django-tz-demo Yeah I saw that. So that's basically the battery compartment, and admin currently doesn't bring timezone batteries. Would be nice if there were some optional batteries, maybe packed separately (django.contrib) but then comes the question of storage... >[...] > As long as Django doesn't have a schema alteration API, it's difficult to > change the User model. > > There's also the question of how to store timezones in the database. If we > implemented this feature, we'd have to bless a timezone implementation. pytz > is pretty much the standard, and it's highly recommended, but it's possible > to use another implementation of tzinfo classes if you desire. > > For these reasons, I think it's better to leave the field open and see what > emerges. I don't want to bless an implementation of "per-user time zone > selection" now, because I don't believe we can come up with a sufficiently > generic one at this point. Maybe when we have more hindsight... That makes sense, thank you. I was personally dreaming of a pytz-based optional app where each relevant component could be replaced. Maybe a thirdparty app will provide this and mature until it gets added. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auto_now=True fields aren't updated on QuerySet.update()
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/Helsinki')
> In [18]: localtime(now()).date()
> Out[18]: datetime.date(2012, 2, 20)
>
> So, the date is affected by the current time zone.
You weren't handling date objects, just asking datetimes for their date.
As you said, nothing surprising here, but I don't understand how this
is "dangerous":
> DateField(auto_now=True) together with USE_TZ, some user will see
> last_edited either in the future, or in the past.
Timezone-aware that's what I would expect.
Using your above example, if I'm in Sydney saving a model instance,
the date will be 21 Feb. No timezone in it.
What else would you want to express with "auto_now" - if you have two
users in different timezones, whose date is the "authoritative" one?
Cheers,
Danny
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: auto_now=True fields aren't updated on QuerySet.update()
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 mechanism handling them. If USE_TZ is True by default, users without timezone experience should be advised that "today" can also be a matter of location. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auto_now=True fields aren't updated on QuerySet.update()
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 a DateField should be updated > with ``timezone.now().today()``, and TimeField should be updated with > ``timezone.now().time()``, no? If I'm in EST time, and the server is > in MST, and it's 11:00PM on the server, my records should be updated > as the following day, since it's 1:00AM EST. Is this naive to assume > (if not, apologies for my lack of know-how regarding TZ issues)? There's a logic to either way, but I agree that auto_now for a date should use the user's timezone to determine "today", not the server's. It would be very weird for me to add a model instance and be told that I did that "tomorrow". Cheers, Danny > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- Kind regards, Danny W. Adair Director Unfold Limited New Zealand Talk: +64 - 9 - 9555 101 Fax: +64 - 9 - 9555 111 Write: danny.ad...@unfold.co.nz Browse: www.unfold.co.nz Visit/Post: 253 Paihia Road, RD 2, Kawakawa 0282, New Zealand "We are what we repeatedly do. Excellence, then, is not an act but a habit." == Caution The contents of this email and any attachments contain information which is CONFIDENTIAL to the recipient. If you are not the intended recipient, you must not read, use, distribute, copy or retain this email or its attachments. If you have received this email in error, please notify us immediately by return email or collect telephone call and delete this email. Thank you. We do not accept any responsibility for any changes made to this email or any attachment after transmission from us. == -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auto_now=True fields aren't updated on QuerySet.update()
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, Django stores date and time information in UTC in the database, uses time zone-aware datetime objects internally, and translates them to the end user’s time zone in templates and forms." > A) If I have a view that simply adds a record of a model with a > datetime field, and 3 users in different timezones load the view at > the same time, all 3 records will have the same datetime value > (assuming, of course, the database was able to write all 3 records > within the same microsecond) They will have the same value in the database, yes. > B) UTC is *the* way to go for almost any application which will have a > timezone = models.CharField(... setting for each user profile See above - database will store everything in UTC. You could use a timezone field like that to store user timezone and activate it, e.g. through a middleware - https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#selecting-the-current-time-zone NB: PostgrSQL already stores UTC internally - https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#postgresql "The PostgreSQL backend stores datetimes as timestamp with time zone. In practice, this means it converts datetimes from the connection's time zone to UTC on storage, and from UTC to the connection's time zone on retrieval." For other backends that store naive datetimes "in UTC" means "assumed as being UTC". > C) When each user has a timezone setting, it doesn't affect the > datetime that's entered into the database, it just gives me the > ability to display the time to them in their timezone It doesn't affect the database. But it's up to you (middleware) to "activate" their timezone in order to make it the "current" timezone. If you don't do that, the "default" timezone (TIME_ZONE setting) will be the current timezone. Whatever a user enters in their "current" timezone is converted to UTC for storage - UTC is the only sane "common denominator". Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auto_now=True fields aren't updated on QuerySet.update()
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 a date with auto_now=True is useless. Can you think of an example that's not? I haven't been able to yet. > I really, really think the date should be UTC date. That is what you > are going to do comparisons against in the DB. In other words, once > you put the date value into the DB, it will be in time zone UTC in > there when you compare it against any datetime value! That goes together with your comment below about the default timezone always being UTC. If I'm in Sydney and the server's TIME_ZONE is Helsinki, either choice will be converted. The question was if TIME_ZONE is not UTC then whose "today" should it be? And in that case I just find the user's "today" more logical than the server's. But again, this is only a problem for an "auto_now" date which I can't think of a sensible use case for. > In addition, I will once more say that if settings.USE_TZ = True, then > the Python process default time zone should be UTC. When using time Sorry I more or less just joined the discussion - I assume you mean by that TIME_ZONE should not be configurable if USE_TZ is True, but rather be fixed to UTC. > zone aware datetimes, they are handled as UTC datetimes in the Python > process. I can't see any point why the time zone for the process > should be something else? What is gained by that? Isn't using Europe/ > Helsinki for the process timezone downright dangerous due to daylight > saving times? Am I missing something obvious here? What is gained by that is that there's a default "activation" in case you don't provide one of your own. At least that's what I understood the interna to do (always work with UTC, convert to localtime for output, default to TIME_ZONE) If that's not the case, I agree, "working" with a local time is very dangerous. Nice example at http://pytz.sourceforge.net/#problems-with-localtime I would personally prefer if timezone was part of auth.User, activation built-in and always done, and TIME_ZONE always UTC. Aymeric's response was: "As long as Django doesn't have a schema alteration API, it's difficult to change the User model. There's also the question of how to store timezones in the database. If we implemented this feature, we'd have to bless a timezone implementation. pytz is pretty much the standard, and it's highly recommended, but it's possible to use another implementation of tzinfo classes if you desire." which makes sense to me. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Possible bug with admin inlines
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 really really small corner case > that most people will never stumble upon? Just want to add that's not the only place where this can happen. If you hook into the post_delete() delete signal of a model with a FK, your method can't access the FK object if it's a cascaded delete invoked by the FK object's delete(). I always wondered why children don't get deleted first (which is how the database _has_ to do it anyway). My workaround is to delete in the correct order myself but I wish I didn't have to. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Possible bug with admin inlines
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 expected. Good to hear! (and a jquery one-liner can swap the way they are displayed) And reading this thread gave me an idea of a slightly cleaner workaround: - either define FK as nullable or provide a "sentinel" FK object for collecting "deletables" - set the FK .ondelete to SET_NULL or SET with a callable that assigns the sentinel - in the FK object's post_delete() - need to doublecheck if that gets called last as well -, clean out all the objects referencing None/sentinel But it's still just a workaround. It appears to me like deleting dependent objects first would avoid the problem altogether (can't think of negative side effects). Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
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 think that's also the problem with Clay's original post:
Do you want to authenticate against email or also change the User model?
What if I want to authenticate against email but still have a username ("nick")?
Another setting?
An auth backend that checks against the email address (which is
already in the User model just like username) _is_ simple.
Rapid and simple would be to _ship_ such a backend in contrib.auth.backends.
Then it would really just be a single setting (AUTHENTICATION_BACKENDS
= ('django.contrib.auth.backends.EmailBackend',)).
The only thing left would be the label on the login template in my
naive understanding. (another one-liner I believe)
So I agree it would be nice and useful, but where's the monkeypatching.
If you want to authenticate against email _and_ take the "username"
out of the model, it's that second part that's the problem. That's
where I believe a set of settings and conditions is a kneejerk
workaround.
Cheers,
Danny
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
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 don't want a username at all when authenticating against email. It would have to be not required and check required fields in clean() where the backend could be asked what's really required. And there's Mr. Schema Migration again... Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
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 >[...] I'm sorry I don't know if I like that. I hope I understand correctly what you're doing, and that my criticism is seen as constructive. This sells itself as "pluggable auth" but really only provides the originally requested auth by email, and I don't see how it could go from there, i.e. what else would be possible (in regards to auth). Pulling username and email out of (Base)User and then bringing one or both of them - and the logic of which to check - back in, is not really a pluggable auth. It's the mixing of profile and information relevant to authentication (and authorization - is_staff?) that's another problem of the existing User model, and this is where this approach allows for dangerous developments. You've pulled those two out and said it's up to the chosen auth to decide a) which to even include in the User model b) which is used to authenticate and which is just "secondary" user (profile?) information. What about first_name and last_name? Why can't a pluggable auth dump those from the User model? And certainly an "auth" should get to have a say about "password". And then... there's not much left anymore in that (Base)User model, right... (GSoC: "reducing the user table to little more than an identifying primary key") Ok email auth problem solved. But now there's a simple way of providing any User model I like, so first thing I'm going to do is to bring in what I think the User should look like i.e. use the "auth" to define what really is a "profile". And so will lots of projects. "The User model needs a username for this app to work". "The User model needs a timezone for this app to work". etc. I'd like to see a later, "proper" auth.user that can undo that chaos. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: authentication by email
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 model. As lame as that may be - at least a later, "proper" auth.user solution would only have two known (shipped) auths to deal with. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: auth.User refactor: reboot
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 the > pieces together. In my latest project there's a situation where neither is useful. We have a Person model (name, address, phone, FK company etc.), and that person may or may not (yet!) have a User account. Person gets a nullable FK from User and we have to listen to post_save() on both of them to synchronize first_name/last_name/email. Would be awesome if such a use case was covered. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GitHub migration planning
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 Saturday, 21 April 2012 22:52:01 UTC+10, Luke Plant wrote: >>[...] Some of the discussion happened on django-core. >> One of the reasons for this was that it affects core developers most of all >>[...] And I guess that's the reason that we didn't have >> further discussion on django-devs - since it already needed a BDFL >> decision, there was no point making the pretence of discussion in a >> wider forum. [...] This doesn't seem odd to me. Makes perfect sense imho. Cheers, Danny -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
