Unable to label address book fields

RESOLVED WONTFIX

Status

Thunderbird
Address Book
--
enhancement
RESOLVED WONTFIX
12 years ago
6 years ago

People

(Reporter: Mats Larsson, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8) Gecko/20051205 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8) Gecko/20051205 Firefox/1.5

This is a follow up bug report to bug id 119291 in order to level up with enterprise features already implemented in Netscape 4. In comment 44 Dan Mosedale once urged me to report this as a new bug report and now I am ;).

Reproducible: Always

Steps to Reproduce:

Comment 1

12 years ago
(In reply to comment #0)
> 
> This is a follow up bug report to bug id 119291 in order to level up with
> enterprise features already implemented in Netscape 4. In comment 44 Dan

i.e. bug 119291 comment 44
> This is a follow up bug report to bug id 119291 in order to level up with
> enterprise features already implemented in Netscape 4. In comment 44 Dan
> Mosedale once urged me to report this as a new bug report and now I am ;).

So what is the actual enchancement request? Is it that you want a UI front end for setting up the ldap address field mappings?
(Reporter)

Comment 3

12 years ago
(In reply to comment #2)
> So what is the actual enchancement request? Is it that you want a UI front end
> for setting up the ldap address field mappings?

From my point of view it's enough if I can specify the addressbook label fields through prefs. If you re-map ldap attribute 'nickname' to attribute 'uid' (as I do at our site) it is vital that you can re-map addressbook label field 'Nickname' to label field 'User ID'.
(Reporter)

Comment 4

12 years ago
Any progress?
(In reply to comment #3)
> From my point of view it's enough if I can specify the addressbook label fields
> through prefs. If you re-map ldap attribute 'nickname' to attribute 'uid' (as I
> do at our site) it is vital that you can re-map addressbook label field
> 'Nickname' to label field 'User ID'.
> 

I'm not sure if re-labelling is really appropriate for items like Nickname. For instance, if a user makes a copy of the card to their personal address book, export it/copy it to someone else/another (non-modified) version of Thunderbird, then the User ID that you have put in there, will show up as nickname, and could be very confusing to the user.

Now I know its possibly not the use-case in your instance, but I could see it happening.

I think in this case it would be better for us to allow re-mapping of the name of just the custom fields (which is another bug somewhere). I'm also doubtful as we could essentially end up with users being able to remap most fields in the address book, which IMHO is not a really necessary function, if we provide most of the required fields in the first place and maybe extend the custom functionality in a better way as well.
(Reporter)

Comment 6

12 years ago
(In reply to comment #5)
 
> I'm not sure if re-labelling is really appropriate for items like Nickname. For
> instance, if a user makes a copy of the card to their personal address book,
> export it/copy it to someone else/another (non-modified) version of
> Thunderbird, then the User ID that you have put in there, will show up as
> nickname, and could be very confusing to the user.
> 
> Now I know its possibly not the use-case in your instance, but I could see it
> happening.

Point taken.

> I think in this case it would be better for us to allow re-mapping of the name
> of just the custom fields (which is another bug somewhere). I'm also doubtful
> as we could essentially end up with users being able to remap most fields in
> the address book, which IMHO is not a really necessary function, if we provide
> most of the required fields in the first place and maybe extend the custom
> functionality in a better way as well.

Sounds like a good enough strategy too me. Then I could assign ldap attribute 'uid' to a custom attribute and then label this custom attribute "User ID". When ;)?
(In reply to comment #6)
> > I think in this case it would be better for us to allow re-mapping of the name
> > of just the custom fields (which is another bug somewhere). I'm also doubtful
> > as we could essentially end up with users being able to remap most fields in
> > the address book, which IMHO is not a really necessary function, if we provide
> > most of the required fields in the first place and maybe extend the custom
> > functionality in a better way as well.
> Sounds like a good enough strategy too me. Then I could assign ldap attribute
> 'uid' to a custom attribute and then label this custom attribute "User ID".
> When ;)?

In which case I'll dup this to bug 37774 (ability to rename Custom 1-4 fields in address book). Its got a patch on, but that will need work though looks like it shouldn't be too hard to implement.

*** This bug has been marked as a duplicate of 37774 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 8

12 years ago
(In reply to comment #7)

> In which case I'll dup this to bug 37774 (ability to rename Custom 1-4 fields
> in address book). Its got a patch on, but that will need work though looks like
> it shouldn't be too hard to implement.
> 
> *** This bug has been marked as a duplicate of 37774 ***

I believe I misunderstood you earlier. This is not a dup of bug 37774. According to that bug you should be able to manipulate your personal address book labels (which I can't even see in Mozilla/Thunderbird).

This is about an enterprise feature for LDAP servers that was present in Netscape 4 and got halfway implemented when bug 119291 was fixed. Dan Mosedale asked me in bug 119291 comment 44 to file another bug to get the rest fixed.

At our enterprise I autoconfig this:

  lockPref("ldap_2.servers.default.attrmap.Company", "ou");
  lockPref("ldap_2.servers.default.attrmap.Department", "departmentnumber");
  lockPref("ldap_2.servers.default.attrmap.DisplayName", "ericn");
  lockPref("ldap_2.servers.default.attrmap.NickName", "uid");
  lockPref("ldap_2.servers.default.attrmap.WorkPhone", "eritelephonenumber");

which works very nice for our LDAP server. The only problem left is that the title bar looks like this

Name   Email   Nickname   Organization   Department   Work Phone
----------------------------------------------------------------

and I want it to look like this for our LDAP server

Name   Email   User ID   Company   Department   ECN Phone
---------------------------------------------------------

I don't see any problem regarding personal address books with this since it only should be configurable through prefs. If anyone saves an LDAP entry to his personal address book it only affects him. I'm reopen this bug since I really like it to be fixed.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(In reply to comment #8)
> (In reply to comment #7)
> I believe I misunderstood you earlier. This is not a dup of bug 37774.
> According to that bug you should be able to manipulate your personal address
> book labels (which I can't even see in Mozilla/Thunderbird).

Maybe I'm actually misunderstanding you. That bug is about changing the names of the custom fields (1-4) to something the user desires. These fields can be seen on the "Other" tab of properties of the address book cards. I can't remember if they can be seen in the card list view, but if not, I'd be willing to put forward a patch so they could be seen (via a toggle probably).

> This is about an enterprise feature for LDAP servers that was present in
> Netscape 4 and got halfway implemented when bug 119291 was fixed.

I must admit I don't know exactly how the enterprise feature in Netscape 4 worked.

> At our enterprise I autoconfig this:
>   lockPref("ldap_2.servers.default.attrmap.Company", "ou");
>   lockPref("ldap_2.servers.default.attrmap.Department", "departmentnumber");
>   lockPref("ldap_2.servers.default.attrmap.DisplayName", "ericn");
>   lockPref("ldap_2.servers.default.attrmap.NickName", "uid");
>   lockPref("ldap_2.servers.default.attrmap.WorkPhone", "eritelephonenumber");
> which works very nice for our LDAP server. The only problem left is that the
> title bar looks like this
> Name   Email   Nickname   Organization   Department   Work Phone
> ----------------------------------------------------------------
> and I want it to look like this for our LDAP server
> Name   Email   User ID   Company   Department   ECN Phone
> ---------------------------------------------------------

So, you want to change the name of the field from Nickname to User ID, and some of the other field names? Surely you want that to happen when the user views/previews/prints the card as well? So the easiest way would be to change it for all address books contained within Thunderbird. Which is why I'm suggesting using the custom fields as they are really designed for that.

The other option that I suppose you could do is to produce a localised build of Thunderbird which changes the labels in the properites/dtd files. You could then role this out to all your users.

> I don't see any problem regarding personal address books with this since it
> only should be configurable through prefs. If anyone saves an LDAP entry to his
> personal address book it only affects him.

What I think you have to remember is that the address book will still treat most other fields the same in the back-end. So if you change the name of the field "nickname" to "User ID" on all address books, then if one of your users receives a vcard with the nickname field specified, then puts it into the address book, it will put in the "user ID" field the nickname on the card. This may cause confusion later. If it was a custom field, I don't think this would be a problem.

Ok, so that's probably what I said before just in a different way. I think I'm nervous about users being able to change almost any address book field name. The only other option I can see would be to also change how the back-end treats it which I think would be a very big change.

Maybe if you could explain exactly what you want to be able to do where then it may help me understand (i.e. what field names do you want to be able to change, do you want the viewing/printing/exporting of the cards affected, etc).

Updated

9 years ago
Assignee: mscott → nobody

Comment 10

6 years ago
Mark, what do you want to do with this bug?  Mats' email bounces, so we won't be seeing a reply.

In reply to Mark Banner (:standard8) from comment #9)
>...
> So, you want to change the name of the field from Nickname to User ID, and
> some of the other field names? Surely you want that to happen when the user
> views/previews/prints the card as well? So the easiest way would be to
>...
> Maybe if you could explain exactly what you want to be able to do where then
> it may help me understand (i.e. what field names do you want to be able to
> change, do you want the viewing/printing/exporting of the cards affected,
> etc).
I think I'm going to mark this as wontfix. Changing the name of existing, well-defined fields seems to me to be something that is dangerous for interoperability. Bug 37774 would allow a field to be implemented that did exactly the same thing as I think Mats wanted to do (especially if that was expanded to any number of custom fields).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.