Thanks for a bug report. One option is to edit the contact and change the full-name/file-as based on your needs. The only issue with it is to do it manually, instead of some predefined default order for newly created/imported contacts.

Thanks for your reply. Indeed it is a work around to my problem, but it would be much more flexible and nicer if one could edit the "display name" 
e.g. I'd like to file my friends under "david and Alisson johnson". Then I can search on david, or alisson or johnson and still find them.

But in the Address label I print for invitations or xmas cards it should be printed as "Fam. Johnson". In other examples I want to print the organisation name.

In kaddressbook this is done via the field "display name".
you can choose some standard formats: 
"first, lastname"
"lastname, firstname"
"organisatioin"
"custom"

I hope you will concider such an improvement.

Regards,

Bert

Where do you change this display name, please? I see that the "File under" offers you such options in evolution, but it's part of each contact and requires its editing, so it's quite hard to do for use cases you named above.

Hello Milan,

I don't understand your question. I don't mind that I need to edit the display name manually. I only have to do it in about 10% of the cases. But I don't see such an option with "file under"

File under only gives two options in my case (ubuntu 10.10):
lastname, firstname
firstname lastname

Adding <custom> as  a 3rd option would solve my problem.
I don't want to edit the full name, as that would destroy the firstname/family name information that I want to use.

I'm not completely sure what the "nickname" option is used for. It would also be a possiblity to reuse that one for my purposes. But in that case there should be the option to use the Nickname in as the first line in a formatted addres.

(btw, this all also relates to the other bug I filed regarding not being able to localise the layout of addresses.)

I hope this gives some more background.
Please let me know if you require more information.

Bert

(In reply to comment #4)
> File under only gives two options in my case (ubuntu 10.10):

ubuntu 10.10 doesn't tell me much, we are talking about evolution, not about your distribution, here. (Believe or not, I'm not using ubuntu at all.)

> lastname, firstname
> firstname lastname

Those options are only meant to offer you the "most common" variations on your Full name values. I am, instead of picking from the list, able to write there my own value too. It works like a charm. In other words, the UI doesn't force me to use one of pregenerated values, I can write to File Under just anything.

You should be able too.

> I'm not completely sure what the "nickname" option is used for

I'm not fully sure too, though it's most likely not meant for this purpose, the File Under is way to go.

And indeed I am!! Thanks. I was put on the wrong foot by the way kaddressbook works. Kaddressbook gives an drop down with an explicit "custom" field.
When I started using evolution, "file under" had the same drop down box but without the explicit "custom" So I assumed wrongly that it wasn't there. It simply never occurred to me to try to actually type in that field.
So from a feature request this report reduces to a mere usability improvement request.
But for now I'm totally happy with this solution.

Now the only thing that remains to stand between me and using evolution for printing address tags/stickers is bug 636809: Evolution does not localize the address layout. (location of postal code within the address, etc.
Do you have any hints on that one? (maybe I overlooked something there too:-)

Regards and thanks again.

Bert

I'm back on this problem. 

First of all I can't seem to edit "file under" in some cases (evolution 3.2.1 under ubuntu 11.10) Haven't found a pattern however..

Also everytime I touch the full name, the "file under" field gets updated.
A better behaviour would be to leave "file under" unchanged when it is eddited manually and only update it again after a standard format is chosen again, e.g.:
lastname, firstname
firstname lastname

Regards,

Bert

What does it do when "cannot edit"?

And the full name change => "file under" changes, well, I would open a new bug report for it, an enhancement request, though that will be possible to do only when editing full name in the dialog, not inline in the edit, because the code around (I can think of at the moment) may consist of:
  - remember last full name values
  - when changing full name, check whether file-as is some predefined value
    from remembered full-name values and change it only if it is
  - remember new full name values as those last
and that can be kinda tricky, thus I would rather WontFix it, if filled, anyway.

Created attachment 203015 [details]
screenshot of contactdialog in Kontact

Sorry for being to brief.

Can not edit in this case means that all changes to the "file under" field are not saved when I press OK. When I open the contact again, the name in "file under" is the same as before editing.

About the other problem I described, Maybe we have to go back to the source of the request: I have contacts in my address book with first name, lastname, etc.e.g: John and Irene Smith 
However, when printing addresslabels I would like to have an alternative name on the label, like Fam. Smith.

One way is to edit the full name field. But a) Then I get a lot of Fam-s in my address book and b) I loose information about the first names. Moreover, I have the above problem that I can't seem to edit the "fullname" and "file under" fields independently.
 
There are several alternative option: One way is to add an alternative field "display name". where I can fill in "Fam. Smith". This is used in the KDE addresbook (see attached screendumps)

Second Alternative, and possible easier is to use the "nickname field". The only change would be to add a tick mark weather to use the nickname in the formatted_address.

Regards,

Bert

P.S. Initially attached the wrong screenshot, how can I delete it?

Created attachment 203017 [details]
fullsize screenshot of contact dialog in Kontact

Created attachment 203018 [details]
dropdown menu from "display name" field

OK, I think I can reproduce the other issue. But first, we are dealing here with three things now, right? And even before, the screen shots, I agree that "Display name" is an equivalent for evolution's "File under" field. The thing is that this attribute is not a standard vCard attribute, thus different clients can store it in a different field. Evolution is using "X-EVOLUTION-FILE-AS".

Back to the issues, I see:
a) the initial one, "full name overwrite". It is done, because we had it 
   explained and bot agree on NotABug resolution, I hope
b) how to use different fields (like Nickname) in printouts, instead of
   File Under field.
c) the File Under is not sometimes saved correctly.

The b) and c) should be filled as separate bug reports, to not steal the original bug.

Nonetheless, I think I found a pattern for the c). Basically, everything works fine if I pick a File Under from the suggested values, it also synchronizes values between itself, which is nice (I can edit full name, add there Middle name or even change First/Last name directly in the Full Name field and the File Under field is correctly updated, but if I change its value to a custom string, I used "custom", then this value is not updated on any change in Full name, which is expected, but the value is not saved either, because on save my "custom" string is replaced with the first suggested value from the File Under combo, which is wrong.

With respect of b), I'm wondering how you print those addresses, because neither view seems usable for this purpose to me.

Thus, as I said, please file bugs for separate issues, write their numbers here and we can move there to investigate each thing separately. Thanks in advance.

Hello Milan,

Thanks for your long reply.
Let me use your list of 3 points to reply.
a) First of all, the core of my problem is that I want to be able to change the name in the formatted address.

Initially I agreed with you that "display name" and "file under" were equivalent. However, after checking the vcard layout of Kontact and Evolution and digging somewhat deeper, I now see there is a difference. Display name is equivalent to the name field. For one, because that field is used directly in the formatted address, both in Evolution and in Kontact, and secondly because both fields are stored in the Vcard field FN
Kontact then stores the "Name" field in the Vcard N field.

This makes some sense, with the Name field, you can specify exactly the title, first, second, middle and last name and suffix. and keep these stored seperately
With the full name field, you are then free to edit it with anything you want to put in the formated address.Meanwhile some suggestions are given to fill the fullname/display name field from the name field, but you are free to fill it customized.

Evolutions instead keeps the FN and N field in sync, not allowing them to deviate. The extra "File Under" field is then used as a 3rd name field for some reason that confuses me at this moment.

b) was an alternative suggestion to my core problem. But it is not very elegant, I agree;-)
c) Indeed, a very seperate bug that I stumbled over in pursue of a solution to this problem. I will file a seperate bug for this.

You asked how I print these addresses. I use glabels, which has a nice interface with evolution. I can put ${Home Address Label} in a text field, select a bunch of contacts, and it prints stickers with the formatted address(vcard field LABEL;TYPE=HOME). Very handy!

Again, thanks for you time discussing this. I hope my explanation above is clear. I tried my best. If not, please let me know.
Regards,

Bert

(In reply to comment #14)
> Evolutions instead keeps the FN and N field in sync, not allowing them to
> deviate. The extra "File Under" field is then used as a 3rd name field for
> some reason that confuses me at this moment.

See the vCard RFC, they are supposed to be kept in sync:
http://tools.ietf.org/html/rfc2426#section-3.1.1

> You asked how I print these addresses. I use glabels, which has a nice
> interface with evolution. I can put ${Home Address Label} in a text field,
> select a bunch of contacts, and it prints stickers with the formatted
> address(vcard field LABEL;TYPE=HOME). Very handy!

OK, then maybe the question should go to glables, at least partially. The result for "${Home Address Label}" is for me:
   Home-Address
   Home-City, Home-State
   Home-Zip
   Home-POBox
   Home-Country
which are fields in Contract's editor. If you'll type into Home-Address field also the name, then it's used from there. Otherwise you can use other fields in glabels too, like ${File Under} or ${Nickname} in front of the ${Home Address Label}, instead of writing the name into the Address field. Both ways should work with your use case, I believe.

> c) Indeed, a very seperate bug that I stumbled over in pursue of a
> solution to this problem. I will file a seperate bug for this.

Thanks.

That is strange. For me ${home Address Label} definitely gives me something that starts with the full-name:
Full-Name
Street, number
City, Postalcode
Country
(The layout is localized for specified country or local country setting, which is why I like to use this field so much.)
Because the Full name is in the Home-address-label, I'm stuck with it, unless I can specify something else to be used in Evolution.
(btw, where does evolution store its addressbook? I couldn't find it. Unless I'm mistaken the label used here is also a standard vcard field (3.2.2 LABEL Type Definition) So glabel just takes what Evolution provides.


Regarding your comment about the RFC, for Full-Name I read:
Type purpose: To specify the formatted text corresponding to the name
   of the object the vCard represents.
To me this doesn't mean it can't be freeformat. It doesn't have to be a formatted copy of the name field. They even have an example:
FN:Mr. John Q. Public\, Esq.
N:Public;John;Quinlan;Mr.;Esq.
Note how Quinlan has been abreviated to Q. in the FN.

In my opinion the best solution would be to have an extra field to edit the Full name, with some predefined values based on the Name field and a "custom" option for exceptions. 

Regards,

Bert

(In reply to comment #16)
> That is strange. For me ${home Address Label} definitely gives me something
> that starts with the full-name:
> ...
> (btw, where does evolution store its addressbook? I couldn't find it. Unless
> I'm mistaken the label used here is also a standard vcard field (3.2.2 LABEL
> Type Definition) So glabel just takes what Evolution provides.

It's accessed by evolution-data-server API. When you save the contact into file, is the LABEL vCard attribute populated with the full name value? It's not for me. If it's not for you too, then ask glabels developers, how it works, as it's completely out of evolution itself in that case.

> Regarding your comment about the RFC, for Full-Name I read:
> Type purpose: To specify the formatted text corresponding to the name
>    of the object the vCard represents.
> To me this doesn't mean it can't be freeformat. It doesn't have to be a
> formatted copy of the name field. They even have an example:
> FN:Mr. John Q. Public\, Esq.
> N:Public;John;Quinlan;Mr.;Esq.
> Note how Quinlan has been abreviated to Q. in the FN.

Evo is more strict then. Thinking of it, it seems like the X-EVOLUTION-FILE-AS was supposed to be FN.
 
> In my opinion the best solution would be to have an extra field to edit the
> Full name, with some predefined values based on the Name field and a "custom"
> option for exceptions. 

Rather not, it's too complicated, too many names and such. Nonetheless, I'm not EBook developer, maybe they will have different opinion for the above things.

(In reply to comment #17)

> > Regarding your comment about the RFC, for Full-Name I read:
> > Type purpose: To specify the formatted text corresponding to the name
> >    of the object the vCard represents.
> > To me this doesn't mean it can't be freeformat. It doesn't have to be a
> > formatted copy of the name field. They even have an example:
> > FN:Mr. John Q. Public\, Esq.
> > N:Public;John;Quinlan;Mr.;Esq.
> > Note how Quinlan has been abreviated to Q. in the FN.
> 
> Evo is more strict then. Thinking of it, it seems like the X-EVOLUTION-FILE-AS
> was supposed to be FN.
That sound good to me. Then I can edit this field and use that in the address label. If that could be the resolution of this "bug" I'd be much obliged. Could this be the way forward?

Regards,

Bert

(In reply to comment #18)
> > Evo is more strict then. Thinking of it, it seems like the X-EVOLUTION-FILE-AS
> > was supposed to be FN.
> That sound good to me. Then I can edit this field and use that in the address
> label. If that could be the resolution of this "bug" I'd be much obliged. Could
> this be the way forward?

I realized it would be a huge change for evolution, it relies on FILE-AS quite heavily. The real solution would be to know why yours glabels fills in the user name for you there, while that mine, glabels 3.0.0, not. There was a bug for prefilling FILE-AS too, but it might not be related here.

I tried replicating your experience. Ubuntu 11.10 contains only glabels 2.2.8,  On 2.2.8 I still get an address label including the name.
I checked a bit further. When I export my addressbook in evolution to vcard, the field  LABEL;TYPE=HOME already contains the FN. So there is no way for 
glabels to remove it again.(see example below) This really is in Evolution!
Maybe your locale setting is for a different country? What if you try the Netherlands for country. Then the formatting should be identical to the example below.

I don't know what X-EVOLUTION-FILE-AS is used for in evolution. A shortcut could be to store the formatted name both in X-EVOLUTION-FILE-AS as in FN for now and decide the fate of X-EVOLUTION-FILE-AS later.

Example Vcard:
BEGIN:VCARD
VERSION:3.0
TEL;X-EVOLUTION-UI-SLOT=4;TYPE=VOICE:+147912982740
ADR;TYPE=home:;;Rio de Janeirosquare 70; Amesfoort;;1234 HI;
CLASS:PUBLIC
FN:James Wailond
N:Wailond;James;;;
REV:2011-12-14T20:28:21Z
UID:pas-id-4D19A7C100000048
URL:
TITLE:
ROLE:
X-EVOLUTION-MANAGER:
X-EVOLUTION-ASSISTANT:
NICKNAME:
X-EVOLUTION-SPOUSE:
NOTE:
X-EVOLUTION-BLOG-URL:
CALURI:
FBURL:
X-EVOLUTION-VIDEO-URL:
X-MOZILLA-HTML:FALSE
LABEL;TYPE=HOME:James Wailond\nRio de Janeirosquare 70\n1234 HI  Amesfoort\n\n
X-EVOLUTION-FILE-AS:Wailond\, James
EMAIL;X-EVOLUTION-UI-SLOT=1;TYPE=OTHER:Jameswailond@gmail.com
END:VCARD

Right, if the name is part of the address label, then glabels cannot do anything with it. I checked the RFC [1] and the Label is created correctly, it can contain the name of the person, even it doesn't work for your needs, unfortunately.

You can edit formats only after bug #636809, which is part of your 3.2.1. The address formats are stored in /usr/share/evolution/3.2/address_formats.dat.
The %n is replaced with the name, thus if you replace any %n with an empty string, then the next time you edit the contact will regenerate the LABEL without name. You can also disable the new formatting by this command:

  $ gconftool-2 --set --type=bool  \
      /apps/evolution/addressbook/display/address_formatting false

I think you've right, we can remove the name part from default address formats, it doesn't look nice in the card view either (I see name and under it address label, where is shown name again. Could you open a new bug report for it, please? I'm sorry it took me so long to understand this (I had the GConf option off, so I didn't spot this on the first look).

[1] http://tools.ietf.org/html/rfc2426#section-3.2.2

(In reply to comment #21)
 
> You can edit formats only after bug #636809, which is part of your 3.2.1. The
> address formats are stored in /usr/share/evolution/3.2/address_formats.dat.
> The %n is replaced with the name, thus if you replace any %n with an empty
> string, then the next time you edit the contact will regenerate the LABEL
> without name. You can also disable the new formatting by this command:

> I think you've right, we can remove the name part from default address formats,
> it doesn't look nice in the card view either (I see name and under it address
> label, where is shown name again. Could you open a new bug report for it,
> please? I'm sorry it took me so long to understand this (I had the GConf option
> off, so I didn't spot this on the first look).
No problem on the time. Thanks for your persistence on this one. You are a great Triager!

Bug #636809 was filed by myself. And I'm very happy with the resolution. I can now create address labels for my international set of friends.

Your proposed resolution to the above bug is not exactly what I have in mind.
My proposal is to store X-EVOLUTION-FILE-AS also in FN for now. That should be simple enough. (the future of X-EVOLUTION-FILE-AS can then be decided later)
Removing the name from the address is most like not even in line with RFC2426, as it results in an incomplete address label.
Solving the "ugly" card view (I don't have a real problem with that) can be solved by not displaying full-name, and only the address label, if you want.

Regards,

Bert

(In reply to comment #22)
>...

My first part was meant as a quick workaround for the problem, before we deal with the proposed change, the second part.

> Your proposed resolution to the above bug is not exactly what I have in mind.
> My proposal is to store X-EVOLUTION-FILE-AS also in FN for now. That should be
> simple enough. (the future of X-EVOLUTION-FILE-AS can then be decided later)
> Removing the name from the address is most like not even in line with RFC2426,
> as it results in an incomplete address label.

The RFC isn't clear if the name should be there too or not, only the example shows it there, but otherwise there is no explicit demand for it in the RFC. Evolution always treated the LABEL as an address without name, and as you see, it had its advantages (for the glabels). That's the reason why i would like to remove it from the definitions of the formatting too. The reason for a new bug is to give chance to addressbook developers (like Ross) give an idea on it and then follow according to it. I do not want to point them to this bug, because it's too long and kinda hard to read with all the issues being discussed here all together.

> Solving the "ugly" card view (I don't have a real problem with that) can be
> solved by not displaying full-name, and only the address label, if you want.

I would like to avoid that. That's why I prefer the old behaviour too.