Re: Suggestion: Better slugifying of scandinavic characters

[Rudolph]

If it's so difficult, why don't we start with a solution that solves
the problem for almost everyone. If someone encounters characters we
didn't think of, we can always add it to the mapping table...

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: is_approved

[Rudolph]

But what if you want to verify someone's e-mailaddress *and* someone's
name? Then we need two of those fields. IMHO we should keep the User
model as simple as it is right now. If you want to add fields, you
should use model inheritance, but that's still on the to-do list, as
far as I know. The sub-optimal alternative is using a foreignkey to the
User model, use inline editing and set max_num_in_admin to 1.

BTW when can we expect model inheritance? (I'm not asking for a date,
it's ready when it's done. But is it a high priority or low priority
thing?)

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: is_approved

[Rudolph]

I would prefer it if the first name and the last name are removed from
the User model, but it has no priority to me since you can leave them
empty.
IMHO these fields are not that common:
- sometimes the policy is to save initials + lastname (or any other
combination)
- in the Netherlands we also have something like an "in between" name
part which is officially part of the last name, but often stored in a
seperate field. Example: Jan van der Bos. Jan is the first name, "van
der Bos" is the last name, but you want to sort it on "Bos". I don't
know about other countries.

I agree with Bryan that all personal user information should be in the
profile model.

Rudolph

When looking to firstname / lastname from an international point of view


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

sanitizing user input

[Rudolph]

I first posted this on the Django userslist but got no response, maybe
some on this list knows an answer.

Hi,

I wonder what's the preferred way/best practice for sanitizing user
input. Most fields of my models are not allowed to contain HTML tags or
javascript. I could use the striptags filter inside my templates but I
feel more like sanitizing it before it enters the database, so I can
trust the database. I could use the django.utils.html.strip_tags
function inside the save function of my models, but it seems foolish to
me to add this kind of sanitizing for allmost all of my fields (not
DRY). At the moment I do it like this:

from django.utils.html import strip_tags
fields = ('address', 'city')
for field in fields:
self.__dict__[field] = strip_tags(self.__dict__[field])

Maybe the CharField and TextField could have a strip_tags option?

Kind regards, Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: default escaping

[Rudolph]

Hi,

Pro:
- secure by default: you do not miss one variable because you have to
explicitly disable it for a variable, I would prefer a little more
verbose syntax like: {{ variable|noescape }}.

Con:
- explicit escaping is better then implicit escaping (no magic behind
the scenes)

I like your idea of explicitly turning it on or off globally in the
settings. In addition to that idea I would suggest an option to set the
behaviour for a whole Template, something like:

tmpl = loader.get_template('example.csv')
tmpl.auto_escape = False
tmpl.render(context)

You could also skip the idea of globally enabled escaping, and only do
it per template as described above. I'm not sure what I like the most.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: default escaping

[Rudolph]

Hi,

Derek Anderson mentioned the need for different kinds of escaping. So
maybe the syntax should be more something like:

{% autoescape xml on %}

and

{% autoescape javascript on %}

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Proposal: default escaping (and branch request)

[Rudolph]

Hi,

How about adding a command to django-admin.py that scans all the
templates of the project and enabled apps and gives you a list of
templates that have unescaped values in them, maybe even display the
tags/lines concerned. IMHO this could be very valueable info for a
developer.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

limit_choices_to does not limit list_filter in admin interface

[Rudolph]

Hi,

When I limit the choices in a one-to-many field with
"limit_choices_to", then the "list_filter" in the admin interface
should show the same limited choices. Does anyone disagree with this?
Else I file a feature request ticket.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Bug introduced at changeset 4500

[Rudolph]

Hi,

I think I found a bug introduced in changeset 4500 (http://
code.djangoproject.com/changeset/4500). When a min_num_in_admin is
specified without a num_in_admin, the "add" view in the admin
interface gives an exception (and possibly the change view as wel, I
didn't test that). Does anyone else experience this since changeset
4500?

Rudolph


--~--~-~--~~~---~--~~
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 introduced at changeset 4500

[Rudolph]

On Feb 15, 10:53 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-02-15 at 06:02 -0800, Rudolph wrote:
> > Hi,
>
> > I think I found a bug introduced in changeset 4500 (http://
> > code.djangoproject.com/changeset/4500). When a min_num_in_admin is
> > specified without a num_in_admin, the "add" view in the admin
> > interface gives an exception (and possibly the change view as wel, I
> > didn't test that). Does anyone else experience this since changeset
> > 4500?
>
> I did some testing before committing that change, but I may have missed
> this case. I'll have a look at it when I get a chance this morning and
> fix it if I can track down the problem.
>
> Thanks for the heads-up and apologies for costing you some time.
>
> Regards,
> Malcolm

No apologies needed, it's the trunk version after all. Thanks in
advance for your time to correct it.

Rudolph


--~--~-~--~~~---~--~~
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 introduced at changeset 4500

[Rudolph]

On Feb 19, 5:20 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> After a fair bit of head scratching and chasing code paths, I think I
> managed to fix this in the correct way. The update is in revision r4542.
> The problem hadn't ever shown up before because we weren't correctly
> handling min_num_in_admin > num_in_admin cases prior to r4500.
>
> Regards,
> Malcolm

Thanks, I'll test my problem and let you know the result.

Regards,

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

relative of absolute imports

[Rudolph]

Hi,

Some newforms modules contain some "relative" imports of the
newforms.util module. Is this intentional behavior or should we use
absolute imports? As far as I know absolute imports are preferred
because they are less likely to conflict with other modules. I think
relative imports are even deprecated in the near future:
http://www.python.org/dev/peps/pep-0328/.

Rudolph


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [EMAIL PROTECTED]
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: relative of absolute imports

[Rudolph]

Hi,

The subject of this discussion should of course be "Relative or
absolute imports", sorry for the typo. The mentioned relative import
of util is just an example since other modules in newforms are
imported in a relative fashion too.

Thank,

Rudolph


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to [EMAIL PROTECTED]
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: magic-removal: plans/estimates for the trunk-merge?

[Rudolph]

Hi,

If it's so stable since Pycon, why doesn't it get merged into trunk?
The trunk is not a release, but it's the first step towards a new
release. I'm just impatient :)

Rudolph
--
Release early, release often...


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: magic-removal: from django.parts.media.photos import get_thumbnail_url

[Rudolph]

Will django.parts.media get dropped in again soon? I would like it if
the ImageField fully works again.

Cheers,

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Connections not being closed in m-r

[Rudolph]

For me the same, hitting refresh a couple of times creates more and
more of those '[local] idle in transaction' things.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Connections not being closed in m-r

[Rudolph]

I'm not an expert on this subject but if I understand it correctly the
database should accept at least as many connections as Apache can
handle client connections (and if that's too much, you can use
pg_pool)? Allowing a bit more connections would be nice otherwise you
can't at the same time connect with psql (or other apps) to your
database when mod_python uses all the connections.

Perhaps that's an advise that should be in the mod_python docs of
Django. It would also be nice to add the methods to calculate the
maximum number of clients in Apache depending on which MPM one uses
(worker, prefork etc) and depending on the settings for things like
MaxClients, ThreadsPerChild, ServerLimit etc. As I said I'm not an
expert on this subject but I think it's interesting information for
people setting up their Django machines.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

bug in homepage of admin M-R (+solution)

[Rudolph]

Hi,

Magic Removal creates to many "caption" tags on the homepage of admin.
A caption tag should appear only once, right after the table tag, but
Magic Removal puts it above every model-row of the table. In IE6 and
Opera this leads to duplicated captions, in FF and Safari the extra
captions get ignored or are invisible.

Solution, change:
django/contrib/admin/templates/admin/index.html

Put this line:
{{ app.name }}
above the for loop instead of inside it.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: More specific CSS rules for the admin

[Rudolph]

It could be solved by putting the django-admin stuff inside a tag with
a django-admin class. Then ".django-admin p" or ".django-admin
#content" will format only the admin stuff and not your site.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: bug in homepage of admin M-R (+solution)

[Rudolph]

Wow, you fixed this faster than light can travel ;-)

Thanks

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

installperms and/or sqlinitialdata

[Rudolph]

Hello,

I'm trying to generate the SQL code to insert permissions for a
specific app in Magic Removal. The installperms option has been removed
in Magic Removal (this is not yet mentioned on the M-R wiki page!). And
sqlinitialdata just gives me an empty 'begin; commit;'. My model does
have an 'Admin' class. Seems like a bug to me, does anyone else
experience this?

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: installperms and/or sqlinitialdata

[Rudolph]

Yes, I use syncdb all the time, but it would be nice if you could also
let it generate the SQL without executing it.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Simplify admin template overrides

[Rudolph]

It would be nice if there was a simple way to include a bit of XHTML in
the list-view just above the list. That way one could include links
like "download CSV-file", "show statistics" or "help".  Or one could
include a bit of documentation like 'These categories are used to group
your images.' Something like:

class Category(modela.Model):
...
class Admin:
help_text = 'image/category_admin.html'

image/category_admin.html would contain something like:

These categories are used to group your images.
Help
download CSV

And maybe it should also be possible to include some custom XHTML above
the add/change form too. Anyway, such a thing would make it really easy
to customise the admin interface a bit.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: A problem of js option of Admin options

[Rudolph]

Hi,

I recently posted your first suggestion:
http://code.djangoproject.com/ticket/1633. Is this something that
should be built into Django? I think one should be abled to load
javascript files (and other files) from every possible URL and defaults
to the ADMIN_MEDIA_PREFIX.

More on your second suggestion, see
http://code.djangoproject.com/ticket/578 and
http://code.djangoproject.com/ticket/61. As you can see, this is an old
issue, still not solved (I can't see a passwordfield in M-R).

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Slug JS stopped working in M-R?

[Rudolph]

Hi,

It seems like the Javascript for a SlugField stopped working in the
current revision of M-R. Or is it me messing things up... Does anyone
else experience this?

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Slug JS stopped working in M-R?

[Rudolph]

It's working again, the fault must have been on my side.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

A few i18n issues on M-R

[Rudolph]

Hi,

I just posted some issues with i18n in M-R on django-i18n:
http://groups.google.com/group/Django-I18N/browse_thread/thread/26cc1ad95bf845bd

Two of the issues are very easy to solve, by adding 'verbose_name' to
the ManyToMany fields of the User and Group model. For the other issues
I do not have a fix (yet).

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Template tag magic that hasn't been removed

[Rudolph]

Maybe the error message should be a bit more informative. Instead of
telling the programmer the taglibrary isn't in django.templatetags, it
should tell the taglibrary is not found inside one of the
INSTALLED_APPS.

It would be cleaner if one could load taglibraries from every possible
location: it's not very attractive to create an empty app just to have
a place to put the taglibrary (this is what the doc's tell you). On the
other hand, I don't have a better solution (yet).

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Template tag magic that hasn't been removed

[Rudolph]

I just thought of a better solution. Taglibraries are just like
templates:
- they get loaded from paths set in settings.py
- and else they get loaded by the template_loaders

IMHO we could do the same thing for taglibraries.

Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: OneToOneField behavior doesn't match docs

[Rudolph]

Nice fix. I found one problem. When a user "forgets" to set the
OneToOneField and saves the object, Django does not return a nice error
message but throws an exception because Django tries to insert a record
without the primary key set. Some kind of validation should be added to
prevent this. Shall I file a ticket?

The model used to get the exception:

from django.db import models
from django.contrib.auth.models import User

class Profile(models.Model):
user = models.OneToOneField(
User,
)
address = models.CharField(
'address',
maxlength = 150,
)
zipcode = models.CharField(
'zipcode',
maxlength = 50,
)
city = models.CharField(
'city',
maxlength = 100,
)
phone = models.CharField(
'phone',
maxlength = 25,
blank = True,
)
birthday = models.DateField(
'birthday',
)

class Admin:
pass

Cheers,
Rudolph


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Content-Security-Policy header for Django 1.8 SecurityMiddleware

[Rudolph]

Hi,

The SecurityMiddleware in Django 1.8 currently lacks one of the most 
powerful HTTP headers to limit what browsers allow. When correctly 
configured is helps to prevent XSS and other (injection) attacks. At the 
Django Under The Hood sprint (which was an awesome event!) I wrote a pull 
request with tests and documentation: 
https://github.com/django/django/pull/3550, could someone who has been 
working on the new SecurityMiddleware review this pull request? The related 
ticket is over here: https://code.djangoproject.com/ticket/15727

Thanks!

Rudolph

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6acc19d6-2bac-41c2-8203-7d141b166d0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using RequestContext by default in default 500 handler

[Rudolph]

Hi,

You could generate your 500.html file by rendering a different
template file that does get a RequestContext. This way you can use the
MEDIA_URL and things like that without hardcoding them in your
500.html file. Ofcourse you need to regenerate your 500.html file when
you change your settings, but that can be done by a little script.

Rudolph

On Jun 23, 12:28 pm, Jason Davies <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> I have several clients who make heavy use of MEDIA_URL for styling
> their sites.  The pages generated by the default 500 error handler
> look rather ugly without any CSS or images, and the lack of branding
> confuses customers.
>
> The default error handler is easily overridden so that it tries using
> RequestContext first and then falls back to using Context if that
> fails.
>
> I opened ticket #6377 [1] a while ago, but it was closed with a
> comment that the default error handler was written in such a way as to
> lessen that chance of any new exceptions being raised.  I fully
> understand this reasoning, but it seems to me that my patch does fall
> back to using the "plain" Context if any new exceptions are raised,
> thus alleviating the problem mentioned in the comment.  Is there
> something I've missed here?
>
> Any thoughts would be appreciated,
>
> Jason
>
> [1]http://code.djangoproject.com/ticket/6377
--~--~-~--~~~---~--~~
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: More secure user password reset

[Rudolph]

Thanks Simon, for the idea of using a timestamp in the url and in the
hash. A really good idea.

You could shorten the hash to 6 digits by using the HOTP algorithm
(http://www.openauthentication.org/). If we send it in base32 it will
be even shorter. I've got the Python code for HOTP ready and would be
happy to contribute it. The nice thing is that HOTP has been studied
and at the moment can be considered safe.

Thanks, Rudolph
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Check-in of change to is_required=True on BooleanField

[Rudolph]

Hi,

I'm quite suprised behind the arguments made for ticket #5957 (check-
in [7799]). To my opinion "is_required" means that the value is
required to be set to whatever value. In HTML this is a bit
problematic for checkboxes since they submit either "on" or nothing at
all. But a BooleanField could also be represented by a different
widget (for example radio buttons or a drop down list) and then "is
required" does make sense.

After check-in 7799 "is_required" enforces a certain value (in this
case "True") on the BooleanField, while "is_required" on the other
fields enforces that it gets a value. So to my opinion the is_required
attribute now has two meanings, which is a bad thing.

Thanks,

Rudolph
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Generic relations and non-integer primary keys

[Rudolph]

The documentation for Generic Relations uses a PositiveIntegerField
for the "object-id". However some models might have a non-integer
field as a primary key, so it might be good to add a note to the
documentation that a different field type is needed if one of your
models uses a non-integer primary key.

Shall I add a ticket for this and add a patch for the documentation to
include such a remark?

Thanks!

Rudolph
--~--~-~--~~~---~--~~
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: Generic relations and non-integer primary keys

[Rudolph]

> Well, that depends. Would you like the problem to be fixed or not? :-)
>
> Malcolm

I can imagine that it will be complex to fix (lot's of field types). A
note in the docs would be nice since an integer primary key is a
requirement for generic relations. I've opened a ticket that adds this
requirement to the docs:
http://code.djangoproject.com/ticket/7785

Rudolph
--~--~-~--~~~---~--~~
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: Generic relations and non-integer primary keys

[Rudolph]

Yes, that's why the proposed patch for the documentation says that
both must be of the same type:
http://code.djangoproject.com/attachment/ticket/7785/note-about-primary-keys.diff

Rudolph
--~--~-~--~~~---~--~~
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: newforms-admin branch has been merged into trunk

[Rudolph]

Wow, thanks for all the hard work to everyone involved! This is really
awesome!

I'll update the Dutch translations soon. And I'll have to start
preparing my company's 30+ Django projects for this change... ;)

Rudolph
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Title of admin app index view is untranslatable

[Rudolph]

Hi,

I opened a ticket with a patch:
http://code.djangoproject.com/ticket/8644

Jacob marked it post-1.0 because of the "string freeze", but it
doesn't change or add any strings since the title was already marked
as translated. This patch just fixes a bug (actually it just moves one
bracket). I'd like propose to change back to milestone "1.0".

BTW thanks for al the amazing work being done for 1.0 release!

Rudolph
--~--~-~--~~~---~--~~
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: Updating a locale

[Rudolph]

Hi,

The process is documented here:
http://www.djangoproject.com/documentation/contributing/#submitting-and-maintaining-translations

Doing it right now is a good time since strings are frozen until 1.0
releases.

Rudolph
--~--~-~--~~~---~--~~
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: ANNOUNCE: Django 1.0 released

[Rudolph]

Here's to the most fabulous webframework in the world!

Rudolph Froger
--~--~-~--~~~---~--~~
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: Proposal: django.forms.SafeForm - forms with built in CSRF protection

[Rudolph]

I'd like to discuss if forms should try to be secure by default? It's
a bit like the autoescaping discussion.

The new Form class would need to accept dictionaries or request
objects as input. A dictionary is however only accepted if you
explicitly disable CSRF protection:
form = MyForm(request.POST, csrf_protection=False)

We can keep it backwards compatible by introducing a setting which
defaults to:
CSRF_PROTECTION = False
and putting CSRF_PROTECTION = True in the default settings.py file of
new projects. Also encourage the use in the documentation.

In Django 2.0 we set this to True. People would then need to
explicitly turn off CSRF protection globally or on a per form basis.

Thanks, Rudolph
--~--~-~--~~~---~--~~
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: Proposal: django.forms.SafeForm - forms with built in CSRF protection

[Rudolph]

I like Luke's arguments.

A middleware seems like the right place because CSRF protection is
about requests and responses. CSRF protection is more about POST
requests in generic, with HTML forms being a very common type of POST
request.

IMHO the default settings.py file (generated with 'django-admin.py
startproject') should have the middleware enabled by default.

And wouldn't it be possible to enhance the current CSRFMiddleware to
be more flexible, like also work without Django's session middleware?
And add a template tag that inserts the token, for example to be used
in AJAX or forms generated by javascript:

var token = '{% csrf_token %}';


Cheers,

Rudolph
--~--~-~--~~~---~--~~
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: Auto-escaping comitted

[Rudolph]

Thank you very much!

May be I found one corner case. But I'm not sure if this is a bug or a
feature. When using {{ block.super }} is will be escaped, which is
IMHO not the common desired result. One can solve this by using
{{ block.super|safe }}, but perhaps it's even more template-developer
friendly to not escape {{ block.super }} by default.

Kind regards,

Rudolph


--~--~-~--~~~---~--~~
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: Fixtures without a pk

[Rudolph]

Structured markup can only represent tree like organised objects
(without tricks). Maybe we can keep the primary keys inside the
fixtures, but add an optional attribute that indicates that the
primary key for this object is only used to link the objects together
when importing the data?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Fixtures without a pk

[Rudolph]

Hi,

Sometimes fixtures without a pk come in handy because the object in
the fixture is important to the application, but it doesn't matter
which pk is has (and other objects might have been inserted by other
applications, so it's unknown which pk is available). I got the JSON
format working with a pk=null (found this in the tests for the
serializers).
My suggestion:
It would be nice to use the django-admin.py with an extra option to
dump certain data without primary keys. If you like the idea, I'll
file a ticket (and maybe implement it at the upcoming Django sprint).

Regards,

Rudolph
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---