On Wed, 01 Dec 2010 08:49:13 -0000, Roundcube Webmail wrote:
#1487143: Name building in addcontact.inc
-------------------------+-------------------------------------------------- Reporter: andudi | Type: Feature Patches Status: closed | Priority: 5 Milestone: 0.5-stable | Component: Addressbook Version: 0.4.2 | Severity: normal Resolution: wontfix | Keywords:
-------------------------+-------------------------------------------------- Changes (by alec):
- status: new => closed
- resolution: => wontfix
Comment:
I don't like it. Guessing the order of names is just wrong. Maybe it could be improved but not this way.
It was just my need, it fits 80% of my contacts, and the failing 20% I have to edit later.
What do you suggest then? I am willing to improve it, but you must be clearer what you would accept! I could imagine a configurable name order as well...
thanks for feedback Andreas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 01.12.2010 10:03, Andreas Dick wrote:
It was just my need, it fits 80% of my contacts, and the failing 20% I have to edit later.
What do you suggest then? I am willing to improve it, but you must be clearer what you would accept! I could imagine a configurable name order as well...
If I remember gmail has such option, but I don't know if this works on addcontact action. If user prefers e.g. Surname,Forename order it doesn't means sender will prefer it too. What if user has a two (fore)names? What if it is a nick (like mine) or company name? Too much guessing and possible mistakes.
In Roundcube the name field is for display name and it should be not changed in any way (a part of your patch). When name is not specified in address string we're trying to build the (display) name. A possible solution would be to get rid of it and leave display-name empty (currently it's a required field).
If I remember gmail has such option, but I don't know if this works on addcontact action. If user prefers e.g. Surname,Forename order it doesn't means sender will prefer it too. What if user has a two (fore)names? What if it is a nick (like mine) or company name? Too much guessing and possible mistakes.
In Roundcube the name field is for display name and it should be not changed in any way (a part of your patch). When name is not specified in address string we're trying to build the (display) name. A possible solution would be to get rid of it and leave display-name empty (currently it's a required field).
Ok, I agree with your arguments! Another problem (and why I made the patch) is, that the name field is used as CN and thus as key identifier in the LDAP (at least in my setup, others can use the email). So it makes conflicts if it is empty at creating. For me, it would make more sense to try to set the "surname", "firstname" fields directly at this place, but I think this fields are not accessible, isnt it?
My question now: shall I investigate more? Because I can live with my patch for now, and if this topic is planed anyway to be redesigned in the future it makes maybe no sense.
thanks Andreas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On 01.12.2010 12:20, Andreas Dick wrote:
Ok, I agree with your arguments! Another problem (and why I made the patch) is, that the name field is used as CN and thus as key identifier in the LDAP (at least in my setup, others can use the email). So it makes conflicts if it is empty at creating. For me, it would make more sense to try to set the "surname", "firstname" fields directly at this place, but I think this fields are not accessible, isnt it?
I think they are.
Another solution would be to display a confirmation dialog with filled inputs. So, user would be able to change data before adding contact.
Andreas Dick wrote:
If I remember gmail has such option, but I don't know if this works on addcontact action. If user prefers e.g. Surname,Forename order it doesn't means sender will prefer it too. What if user has a two (fore)names? What if it is a nick (like mine) or company name? Too much guessing and possible mistakes.
In Roundcube the name field is for display name and it should be not changed in any way (a part of your patch). When name is not specified in address string we're trying to build the (display) name. A possible solution would be to get rid of it and leave display-name empty (currently it's a required field).
Ok, I agree with your arguments! Another problem (and why I made the patch) is, that the name field is used as CN and thus as key identifier in the LDAP (at least in my setup, others can use the email). So it makes conflicts if it is empty at creating. For me, it would make more sense to try to set the "surname", "firstname" fields directly at this place, but I think this fields are not accessible, isnt it?
My question now: shall I investigate more? Because I can live with my patch for now, and if this topic is planed anyway to be redesigned in the future it makes maybe no sense.
The entire address book is subject to be completely re-written so we should postpone this discussion to that. I've re-opened the ticket and moved it to the according milestone. With more advanced features of the address book the name formatting question will arise anyway.
I think a configuration option for how to compose the "display name" from all the given fields (e.g. surname, middlename, family name, prefix, suffix) will be needed. Of course this doesn't automatically solve the parsing of a given name string into the right components. If you have more inputs or suggestions please let us know. However showing a dialog every time is the least preferred option for me and I don't know any major mail clients that do that.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
On Fri, 03 Dec 2010 17:45:46 +0100, Thomas Bruederli wrote:
inputs or suggestions please let us know. However showing a dialog every time is the least preferred option for me and I don't know any major mail clients that do that.
Not every time. Only when display-name is not specified. Thunderbird for example, doesn't display a dialog, but it allows contacts without display-name.
So, I think optimal solution would be: remove display-name requirement from sql addressbook, display dialog only when addressbook source (e.g.LDAP) requires display-name and it is not specified.