(Migrated) another encoding problem

(This message has been automatically imported from the retired mailing list)

I just discover another bug related to the encoding like the previous I
reported in a GitHub issue.
The scenario now is more simple to test, simply add a character like
=C3=A1,=C3=A9,=C3=AD,=C3=B3 or =C3=BA
to a row at sec_base table in the name field and you will be unable to list
any user and many others models get affected like http or soap channels, at
least from the web-admin point of view
I discover this because my clients are testing the application and they are
creating users in Zato from OpenERP module and they assign those users to
the deployed services channels, they create the users with a qualified
name(login) but the user name value is taken from the partner associated to
this new user, so the partner name can have the any unicode character,

Cheers

Another thing related to the users login(username) is that they are not
unique, you can create 2 or more users with the same username, the only
check to duplicity is for the name, this could cause confusion because we
are talking about the same username with different passwords, one that
works and others than not, even when the sec_def is path_info based this is
weird, and can cause confusion.

On Fri, Jun 6, 2014 at 6:13 PM, Axel Mendoza Pupo aekroft@gmail.com wrote=
:

I just discover another bug related to the encoding like the previous I
reported in a GitHub issue.
The scenario now is more simple to test, simply add a character like
=C3=A1,=C3=A9,=C3=AD,=C3=B3 or =C3=BA
to a row at sec_base table in the name field and you will be unable to
list any user and many others models get affected like http or soap
channels, at least from the web-admin point of view
I discover this because my clients are testing the application and they
are creating users in Zato from OpenERP module and they assign those user=
s
to the deployed services channels, they create the users with a qualified
name(login) but the user name value is taken from the partner associated =
to
this new user, so the partner name can have the any unicode character,

Cheers

On 06/07/2014 01:53 AM, Axel Mendoza Pupo wrote:

Another thing related to the users login(username) is that they are not
unique, you can create 2 or more users with the same username, the only
check to duplicity is for the name, this could cause confusion because we
are talking about the same username with different passwords, one that
works and others than not, even when the sec_def is path_info based this is
weird, and can cause confusion.

Thanks Axel, this will be changed and usernames will be unique within a
given security definition type.

https://github.com/zatosource/zato/issues/260

On 06/07/2014 01:13 AM, Axel Mendoza Pupo wrote:

I just discover another bug related to the encoding like the previous I
reported in a GitHub issue.
The scenario now is more simple to test, simply add a character like
á,é,í,ó or ú
to a row at sec_base table in the name field and you will be unable to list
any user and many others models get affected like http or soap channels, at
least from the web-admin point of view

Axel - how to reproduce it, exactly? Can you please provide what Zato
version it is and step-by-step instructions to make it happen?

thanks,

On 06/07/2014 01:13 AM, Axel Mendoza Pupo wrote:

I just discover another bug related to the encoding like the previous I
reported in a GitHub issue.
The scenario now is more simple to test, simply add a character like
á,é,í,ó or ú
to a row at sec_base table in the name field and you will be unable to list
any user and many others models get affected like http or soap channels, at
least from the web-admin point of view

Axel - how to reproduce it, exactly? Can you please provide what Zato
version it is and step-by-step instructions to make it happen?

thanks,