Session age or session idle timeout?
In this ticket [1] which adds the ability to override the global session age setting, there is a discussion going on regarding whether the override value should set a fixed life for the session or just change the idle timeout. [1] http://code.djangoproject.com/ticket/2548 Currently, if ever the session is accessed, it's expiry date is reset to now + SESSION_COOKIE_AGE Should the override setting: A) work the same way (just changing the idle timeout), B) set a fixed life for the session, or C) offer both options (in which case, which should be the default?) --~--~-~--~~~---~--~~ 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: Volunteering for "Week in Review" postings
Everyone: *** I sent this to Adrian this afternoon and I just wondered if anyone on the list had any feelings on this: I just got back from SF and I am making plans to make my first Django Weekly Update this coming monday. >From my time spent in contact with and working for an organization that's been publishing information online for a long time (Ars Technica), I think it would be most prudent to publish these before noon on Mondays when there are likely to be the most eyeballs. Does this sound reasonable? I'd like to establish a schedule for both exposure purposes and it will be much easier to fit into my daily activities. I have a number of items in my RSS reader at home that I feel might merit inclusion, but by all means please send anything on that you've been hanging on to that you feel would be important to include. I plan to typically prepare each post on the Sunday before it's publication from sources I cull throughout the week so I will probably do a final call for items on this list on Saturday morning. Clint On 6/18/07, Clint Ecker <[EMAIL PROTECTED]> wrote: > ** Sorry guys, I sent this last night from my Blackberry but it looks > like it was using an email address that wasn't registered with Google > Groups, here it is again: > -- > > Hi Chris et. al, > I've been in San Francisco all week for WWDC and I plan to make my > first post this coming week. I've got a handful of links collected in > the first pass of my RSS feeds and I need to do a quick scan over the > recent checkins and big discussions here, though. > > Thanks for the ping! > > Clint > > > On 6/17/07, SmileyChris <[EMAIL PROTECTED]> wrote: > > > > *Ping* Update on "week in review" postings? > > > > > > > > > > > > > -- > Clint Ecker > c: 312.863.9323 > twitter: clint > AIM: idiosyncrasyFG > Gtalk: [EMAIL PROTECTED] > -- Clint Ecker Sr. Web Developer - Stone Ward Chicago p: 312.464.1443 c: 312.863.9323 --- twitter: clint skype: clintology AIM: idiosyncrasyFG Gtalk: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Regular Expression Field Lookups, Take Two
On 6/18/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > modeltests/lookup/models.py looks like the right location. Tests have been added there in the latest patch. > Then the maintainers of [Oracle] should be able to help with > the implementation there. Good to hear. --~--~-~--~~~---~--~~ 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: Message Passing for Anonymous Users
It's not difficult for someone to implement this themselves, but it does seem useful enough (imo) for core. I have also contributed a patch to that ticket (sorry for the hijack) with docs and tests, calling the framework "visitor messages" to keep it separate from auth's "messages" framework. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Message Passing for Anonymous Users
I created a ticket for a new way of passing messages and the first response said that I should bring it up to the dev group for a design decision. http://code.djangoproject.com/ticket/4604 - that's the ticket (with patch). Basically, it stores messages according to session rather than according to user. This way, even if a user is anonymous, you can send them messages. This works out nicely when someone is signing up for the site and you want to pass them back to the homepage with a message (but they don't have their account yet so you can't use user_instance.message_set.create()). It uses a context processor to get the message into the template and middleware to get the message from the view and into the session. I hope you like it! Sean. --~--~-~--~~~---~--~~ 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: International standard for date and time
I'm going to give this one more pass and then dropout. We're just going around in circles now. On Mon, 2007-06-18 at 12:09 -0700, Jonas wrote: > On 18 jun, 00:04, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-06-17 at 06:13 -0700, Jonas wrote: [...] > The problem is that you think that everybody would have to know the > english months names, By default, Django uses (North American) English. So, yes, we do assume people know English when using Django in the default locale. If they don't, that is what the very comprehensive translation infrastructure is for. Month names are not going to be the greatest hurdle for a non-English speaker here. > and to feel comfortable with the USA date > format. > In USA is used: *Month Day Year*. But in another countries the people > could use another formats like *Day Month Year* In many countries multiple variations on the theme are used in different contexts and there isn't mass confusion. Let's try to get past the notion that there is a single format used uniformly throughout any individual country. > > They are all also marked as translatable by Django, so people using > > other languages see localised, similarly unambiguous versions of those > > strings. > I'm agree. But the settings should be set by default to that > international format by I just say in the anterior paragraph. You assert this, but without supporting arguments except pointing to some documents that use benefits and drawbacks we already acommodate. The (extra, not mentioned in the links you gave) reason we can use the current format is that it's a very familiar format for native English speakers. There isn't any ambiguity and it looks like it was written to be read by humans and not computers. Humans think of months as January, February, March, etc, not 1, 2, 3, 4... > > > > Django is a project used by an international community (and grown by > > > that community) and its configuration should be set to an > > > international format by default. > > > > "International format" can mean a lot of things, not all of them good. > > One very strong argument against using an ISO format (which is > > well-defined and is what the original ticket was about) is that it isn't > > a very human-friendly string. If your friends asks you what the date is, > > you don't say "2007-06-18", you say "June 18". The goal of a date format > > is to unambiguously describe the date and time in a way that is > > understood by the reader. That is the main justification given in the > > links you posted earlier, too, if you have a look. However, none of > > those links address the human-readable phase particularly clearly. We > > meet the unambiguous and clear in all locale requirements with our > > current setup. If a website says "today is 2007-06-18 08:52", it is > > designed for people who are very familiar with computers and willing to > > compensate for some odd constructs like that; it isn't written to be > > invisible. > It has not been created to be human-friendly else so that it can be > understood by anyone. This assertion (not user friendly) is not something I can agree with. Month names are particularly friendly to humans. It's why we invented them. Which group of English speakers does not understand June 18, 2007? They may choose to use "18 June 2007" sometimes, but they will understand the reverse format without even thinking, where as "2007-06-18 09:32" requires some parsing (is it this month? next month?...). Do you really say 2007-06-18 when your friends ask you what the date is? Does your grandmother, who doesn't use computers as much as you do, use that format? We are trying to encourage websites that feel natural to all users, not just friendly for people who have used computers all their lives. > That's the function of an international format. It's also a function supported by other formats. This isn't an either/or discriminator. > I don't say that location of date and time shouldn't be used, else > that by defect would have to be selected the international format. Or > perhaps, does Django has the location about date and time for all > countries? I don't understand what you're trying to say here. However, if I'm guessing right, I think your concerns can be addressed by pointing out that if your particular locale has a very uniform date time format and it matches the ISO format, that is something the translator for your locale should be using. The default date and time format strings are all translated strings. So the translator for a locale that always uses ISO format should be putting that format into the PO file for DATE_FORMAT, etc. Realistically, there isn't going be an answer that everybody agrees with 100% for this issue. The fact that you feel it is such a serious thing shows that. However, your proposal also hasn't collected any significant support that has raised issues that aren't already addressed, so I can't see it as a really serious problem with the current
Re: Customizable app/project skeletons
On 6/18/07, Jared Kuolt <[EMAIL PROTECTED]> wrote: > > I have a common set of extra bits that I put in my settings.py files > and re-input them each time I create a project. I would like to have a > directory like ~/.django_skeletons/project that houses my customized > settings.py (and perhaps others). This is already possible: - Create a default settings module somewhere (let's call it "skeleton.py"). - At the top of each project settings file, put: from skeleton import * ... and you're done. ^_^ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Customizable app/project skeletons
I have a common set of extra bits that I put in my settings.py files and re-input them each time I create a project. I would like to have a directory like ~/.django_skeletons/project that houses my customized settings.py (and perhaps others). It seems to me this would be a fairly simple undertaking. Bad idea? Good idea? --~--~-~--~~~---~--~~ 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: Regular Expression Field Lookups, Take Two
On Mon, 2007-06-18 at 09:27 -0500, Tom Tobin wrote: > Context: > http://groups.google.com/group/django-developers/browse_thread/thread/cb0dd0b5ba0ffe11/ > > I would like to submit for (re-)appraisal ticket #1465, which > implements regular expression field lookups (``__regex`` and > ``__iregex``). A newly attached patch is up to date with trunk, and > additionally has both case-sensitive and case-insensitive matching > working for each of the supported database engines. Additionally, the > new patch does *not* implement the admin searching functionality which > was frowned upon during the last discussion of the code. Wow. That's a tiny patch. Good. Makes it easy to review. Looks like you had fairly good support last time around, so this shouldn't be too painful. > The two issues I might see with the current patch are: > > 1) It does not include any tests. I'm quite willing to write them; > it's just a matter of *where* they might go. :-) Of the two primary > test locations, ``regressiontests`` seems wrong as this is not a fix > for an existing bug; ``modeltests``, on the other hand, does not have > a location where the entire current range of field lookups are tested. > (Maybe this, in itself, is something that should be created?) modeltests/lookup/models.py looks like the right location. Where possible, hanging extra tests off existing files is a good approach because every new test file we add requires another database flush and reload and all the other test setup stuff. It takes a long time to run the tests at the moment and when you're doing it a few dozen times a day, the extra time starts to add up. > 2) It lacks support for two of the included backends: ``oracle`` and > ``ado_mssql``. If developers using either of these backends are aware > of how to implement regular expression matching, feel free to ping me > and/or the ticket, and I'll gladly include the code. The ado_mssql backend is completely unsupported (we should probably think about removing it at some point), so I wouldn't worry about that. The existing oracle backend is also unsupported. Very shortly (maybe even today if things go smoothly), I'll merge the boulder-oracle sprint branch into trunk so that we will have a supported Oracle backend. Then the maintainers of that portion of the code should be able to help with the implementation there. Once we have Oracle merged, it will be at the point where it's very impractical to expect patch writers to have tested against each supported backend, because installing and running Oracle is non-trivial. 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: Bug with generic relations that span other relationships?
FYI, here's the quick linkto that ticket.
http://code.djangoproject.com/ticket/3906
On Jun 17, 3:12 pm, Jamie Norrish <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-06-17 at 20:25 +, [EMAIL PROTECTED] wrote:
> > The call to Comment.objects.filter(poll=p) generates the following raw
> > SQL (comment columns are replaced by * for brevity):
> > SELECT * FROM "comments_comment" LEFT OUTER JOIN "comments_comment" AS
> > "m2m_comments_comment__poll" ON "comments_comment"."id" =
> > "m2m_comments_comment__poll"."object_id" WHERE
> > ("m2m_comments_comment__poll"."object_id" = 47)
>
> > Clearly, we have an incorrect join here. It makes no sense to join
> > the comments_comment table on itself.
>
> This looks very much like the same behaviour as I reported in ticket
> #3906.
>
> Jamie
--~--~-~--~~~---~--~~
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: International standard for date and time
On 18 jun, 00:04, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2007-06-17 at 06:13 -0700, Jonas wrote: > > The current settings already are unambiguous *only for north > > americans*. > > I'm sorry, but this simply isn't true. > > - Current default DATE_FORMAT is "N j, Y" which, right this > minute, produces "Jun. 18, 2007". > > - Current default DATETIME_FORMAT is 'N j, Y, P' which produces > "Jun. 18, 2007, 8:52 a.m.". > > - Current default TIME_FORMAT is "P" which produces 8:52 a.m. > > - YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT similarly use words for > the month and four digit years. > > None of those are ambiguous. You might quibble (as I would) that using > month abbreviations rather than thefull name there is a flaw, but it's > not fatal and there is absolutely zero doubt about what month, date, > year, hour, minute and half of the day is being referenced. No matter > what your particular locale, providing you know the English month > names. The problem is that you think that everybody would have to know the english months names, and to feel comfortable with the USA date format. In USA is used: *Month Day Year*. But in another countries the people could use another formats like *Day Month Year* > They are all also marked as translatable by Django, so people using > other languages see localised, similarly unambiguous versions of those > strings. I'm agree. But the settings should be set by default to that international format by I just say in the anterior paragraph. > > Django is a project used by an international community (and grown by > > that community) and its configuration should be set to an > > international format by default. > > "International format" can mean a lot of things, not all of them good. > One very strong argument against using an ISO format (which is > well-defined and is what the original ticket was about) is that it isn't > a very human-friendly string. If your friends asks you what the date is, > you don't say "2007-06-18", you say "June 18". The goal of a date format > is to unambiguously describe the date and time in a way that is > understood by the reader. That is the main justification given in the > links you posted earlier, too, if you have a look. However, none of > those links address the human-readable phase particularly clearly. We > meet the unambiguous and clear in all locale requirements with our > current setup. If a website says "today is 2007-06-18 08:52", it is > designed for people who are very familiar with computers and willing to > compensate for some odd constructs like that; it isn't written to be > invisible. It has not been created to be human-friendly else so that it can be understood by anyone. That's the function of an international format. I don't say that location of date and time shouldn't be used, else that by defect would have to be selected the international format. Or perhaps, does Django has the location about date and time for all countries? --~--~-~--~~~---~--~~ 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: Merged Per Object Permissions (RLP) Branch
On 6/17/07, Chris Long <[EMAIL PROTECTED]> wrote: > Please let me know of any problems, complaints, compliments, etc. with > the RLP branch. Hi Chris, If you haven't already, check out the newforms-admin branch. We've added a bunch of extra hooks to the admin, and it's already possible to do row-level permissions with a hook called has_change_permission(). See http://code.djangoproject.com/wiki/NewformsAdminBranch for more details. It's probably still worth implementing your RLP stuff, as there's a difference between yours and what's in the existing newforms-admin branch -- the newforms-admin branch uses pure Python to express the permissions, whereas your RLP branch stores the permissions in the database. There are advantages and disadvantages to both approaches. It may even be possible to implement a database-stored RLP framework *on top of* the newforms-admin has_change_permission() hooks, which would be really nice. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
'retrieve': the missing permission?
Hi, I've just tried to use the permission_required decorator for my views and I realise that there is a missing 'retrieve' permission. It's a bit odd because others ones follow the CRUD permissions. Am I missing something here? The patch is trivial: Add 'retrieve' to the auth.management._get_all_permissions function, but I don't want to hack my django code so I wonder why this choice had been done? (I suspect the admin goal which is driven by the User.is_staff field but auth can be used elsewhere). David --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Regular Expression Field Lookups, Take Two
Context: http://groups.google.com/group/django-developers/browse_thread/thread/cb0dd0b5ba0ffe11/ I would like to submit for (re-)appraisal ticket #1465, which implements regular expression field lookups (``__regex`` and ``__iregex``). A newly attached patch is up to date with trunk, and additionally has both case-sensitive and case-insensitive matching working for each of the supported database engines. Additionally, the new patch does *not* implement the admin searching functionality which was frowned upon during the last discussion of the code. The two issues I might see with the current patch are: 1) It does not include any tests. I'm quite willing to write them; it's just a matter of *where* they might go. :-) Of the two primary test locations, ``regressiontests`` seems wrong as this is not a fix for an existing bug; ``modeltests``, on the other hand, does not have a location where the entire current range of field lookups are tested. (Maybe this, in itself, is something that should be created?) 2) It lacks support for two of the included backends: ``oracle`` and ``ado_mssql``. If developers using either of these backends are aware of how to implement regular expression matching, feel free to ping me and/or the ticket, and I'll gladly include the code. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Password reset form with non unique email addresses
The PasswordResetForm in django.contrib.auth.forms assumes that there
cannot be more than one user with the same email address (see the
isValidUserEmail method), even though there is no database level
constraint for this. So the corresponding view,
django.contrib.auth.views.password_reset, can give you an 'Internal
Server Error' if you have users who share email addresses, as I do.
This use case is not so strange as it seems -- married couples sometimes
seem to share email addresses, but they may need different accounts on
a website.
So, the attached patch changes the form to reset *all* usernames for the
given email address. This isn't perfectly ideal behaviour, but it
seems better than the alternatives (e.g. not allowing password resets
where you have duplicate email addresses). Asking the user "which
account do you want to reset?" would add a lot of complication to the
form for a very small use case. The only downside is that the
passwords for all relevant accounts have been reset, but the person who
has done this will realise this has happened as he/she will by
definition get both emails (which contain already contain the username
that has been reset).
Any objections to me committing this?
Thanks,
Luke
--
"Making it up? Why should I want to make anything up? Life's bad enough
as it is without wanting to invent any more of it." (Marvin the
paranoid android)
Luke Plant || http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Index: django/contrib/auth/forms.py
===
--- django/contrib/auth/forms.py (revision 5490)
+++ django/contrib/auth/forms.py (working copy)
@@ -79,32 +79,32 @@
def isValidUserEmail(self, new_data, all_data):
"Validates that a user exists with the given e-mail address"
-try:
-self.user_cache = User.objects.get(email__iexact=new_data)
-except User.DoesNotExist:
+self.users_cache = list(User.objects.filter(email__iexact=new_data))
+if len(self.users_cache) == 0:
raise validators.ValidationError, _("That e-mail address doesn't have an associated user account. Are you sure you've registered?")
def save(self, domain_override=None, email_template_name='registration/password_reset_email.html'):
"Calculates a new password randomly and sends it to the user"
from django.core.mail import send_mail
-new_pass = User.objects.make_random_password()
-self.user_cache.set_password(new_pass)
-self.user_cache.save()
-if not domain_override:
-current_site = Site.objects.get_current()
-site_name = current_site.name
-domain = current_site.domain
-else:
-site_name = domain = domain_override
-t = loader.get_template(email_template_name)
-c = {
-'new_password': new_pass,
-'email': self.user_cache.email,
-'domain': domain,
-'site_name': site_name,
-'user': self.user_cache,
-}
-send_mail('Password reset on %s' % site_name, t.render(Context(c)), None, [self.user_cache.email])
+for user in self.users_cache:
+new_pass = User.objects.make_random_password()
+user.set_password(new_pass)
+user.save()
+if not domain_override:
+current_site = Site.objects.get_current()
+site_name = current_site.name
+domain = current_site.domain
+else:
+site_name = domain = domain_override
+t = loader.get_template(email_template_name)
+c = {
+'new_password': new_pass,
+'email': user.email,
+'domain': domain,
+'site_name': site_name,
+'user': user,
+}
+send_mail('Password reset on %s' % site_name, t.render(Context(c)), None, [user.email])
class PasswordChangeForm(oldforms.Manipulator):
"A form that lets a user change his password."
Re: Return unicode from template's render
Malcolm Tredinnick wrote: > That sounds reasonable. Just was about to make a patch but saw your changeset implementing it. Thanks! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
