On Tuesday, August 5, 2014 8:45:05 PM UTC+2, Collin Anderson wrote:
>
> Could we handle it with model validation on a custom user model? Maybe add
> a validate_password() method on the user model?
I don't think so, using a custom user just for password validation is way
to much work given that
Hi all,
Sorry if I didn't explain myself clearly, I will try to do it better. It
will be nice to contribute something to Django.
What I a propose is to provide a view to retrieve the i18n translations
catalog as JSON, this is something that was requested in the ticket:
Could we handle it with model validation on a custom user model? Maybe add
a validate_password() method on the user model?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it,
On 08/05/2014 03:42 AM, Areski Belaid wrote:
> I also agree with you that custom storage will be more elegant solution.
>
> On the other hand it seems to me that reusing the same file on upload
> will not allow a clean management of user's resources, for instance if a
> user decide to delete a
In fact, there is an accepted
ticket: https://code.djangoproject.com/ticket/16860
It may be better to try out the "AppConfig setting" route as discussed
in https://groups.google.com/d/topic/django-developers/qnnCLppwA3o/discussion
rather than adding a new top level setting.
Perhaps you can
First of all, apologies in advance if this is not the right place for this
or if this topic has already been brought up. Long time listener, first
time caller.
I would like to propose having some sort of password validation layer that
can be activated every time a user's password is created or
Hi Daniel,
I'm a little confused because if I understand correctly you introduced the
concept of "data" field that you describe as "any field that has an entry on
the database", but how is that different from the earlier concept of "concrete"
fields.
For now FO, FK and O2O all fall under the
On Mon, 2014-08-04 at 13:02 -0700, Daniel Pyrathon wrote:
> Hi All,
>
>
> The current Options implementation has properties for "concrete
> fields".
> Technically speaking, concrete fields are data fields without a
> column.
Concrete fields are data fields *with* a column, not the other way
I also agree with you that custom storage will be more elegant solution.
On the other hand it seems to me that reusing the same file on upload will
not allow a clean management of user's resources, for instance if a user
decide to delete a file we won't be able to tell if this file is used by
