Note, this should be fixed in trunk now. By default, IS_MATCH will simply
check for a match but will not extract the matching substring (it will
return the entire original value). If you do IS_MATCH(extract=True), then
it will extract only the matching substring (which was the old, incorrect,
behavior).
Anthony
On Friday, December 23, 2011 10:46:12 AM UTC-5, Anthony wrote:
>
> By default, the 'username' field gets the following validators:
>
> (IS_MATCH('[\w\.\-]+'), IS_NOT_IN_DB(db, table.username))
>
> The IS_MATCH is doing the truncating. Actually, I think that's a bug --
> IS_MATCH isn't supposed to transform the input, only check the regex
> pattern. For now, though, I suppose you could overwrite that tuple with
> your own validators:
>
> auth.settings.table_user.username.requires = [IS_MATCH('[\w\.\- ]+'),
> IS_NOT_IN_DB(db, auth.settings.table_user.username)]
>
> Note, I added a space to the IS_MATCH regex.
>
> Anthony
>
> On Friday, December 23, 2011 10:11:44 AM UTC-5, greenguerilla wrote:
>>
>> Hi,
>>
>> I noticed something strange when testing the registration of users.
>>
>> If I attempt to register as user: 'My Name' (note the space), the form
>> validation passes and I get an 'email sent' message.
>> What actually happens though, is the the username gets inserted into
>> the db as 'my'.
>> I'm fine with the lowercasing but I would rather strip the spaces and
>> insert the user as 'myname'
>> I have been searching for a hook to do this and I have tried the two
>> methods:
>>
>> auth.settings.register_onvalidation = clean_username
>> auth.settings.register_onaccept = clean_username
>>
>> Where 'clean_username' is a function to strip all the spaces from the
>> entered text.
>> My problem is that the username has already been stripped by the time
>> it gets this far. Strangely enough this doesn't happen for the
>> username field in the login form.
>>
>> Does anywhere know where this might be happening and how I can
>> override it?
>>
>> Thanks,
>>
>> John
>>
>
