Subscription Request - Automatic Nickname Population

Hey all,

Todd, thanks for your reply in my earlier post. We have found the root cause of our display names issue.

When users receive subscription request, the user defined nickname automatically defaults to the username instead of the nickname, and since user defined nicknames take precedence, there is our issue.

Where can I define (either client or server side) what populates this Nickname field during a Subscription Request?

Thanks much,

Joe

*edit, we confirmed this because when we clear out the nickname field on a subscription request, everything works peachy. Thanks guys!!

the nickname is defined by your vcard mappings. the mappings I gave you should fix the issue. it sets the nickname to the displayName. users cannot change this field.

Where do I change the vcard mappings so that it matches what you gave me?

Just found it. Stupid question. Thanks Todd

system properties ldap.vcard-mapping

Let me see if I can better clarify our situation. We set system property ldap.nameField to “displayName” and are using your recommended settings for our ldap.vcard-mapping. Here is what’s happening:

When viewing the full profile of a user, the correct nickname is populated in the profile information window. See 1.jpg. Good.

When adding a contact, if we hit tab or leave the nickname field blank, the proper nickname is automatically inserted. See 2.jpg and 3.JPG. Good.

BUT, when the other user receives the subscription request, the nickname is incorrectly autopopulated as the username. See 4.jpg. Bad.

This is what I am trying to change, because unless the user specifically deletes that nickname from 4.jpg, it incorrectly sets the nickname for the receiving user.



We worked around this issue by using the “Subscription” plugin so that local users do not receive subscription requests when adding users.

http://www.igniterealtime.org/projects/openfire/plugins.jsp

This would have been my next suggestion. I have mine set to accept local. The issue is actually a client issue. Spark is not populating those fields from the server, but instead is creating the nickname based on what is entered as the username.

another solution is to create shared groups to auto publish to the rosters. these will always display correctly as they are server based not client.

1 Like

This would have been my next suggestion. I have mine set to accept local. The issue is actually a client issue. Spark is not populating those fields from the server, but instead is creating the nickname based on what is entered as the username.

another solution is to create shared groups to auto publish to the rosters. these will always display correctly as they are server based not client.