I am using OpenFire 3.3.3 with AD and Spark 2.5.7 and I find the behavior of the add contact a bit frustrating. I have set on the server to pull the nickname from a particular attribute in the directory, but when the contact is added to the roster it always uses the username field for the display instead of the nickname. It shows the proper nickname in the profile, but ideally if you have a place the nickname is stored it should grab and use that instead. Is there a way to change this behavior?
I completely agree with devmage above - we’re trialling Spark/Openfire in our AD-based network and found this to be an annoyance.
More worryingly though is the search facility when inviting users to conference rooms i.e. it only accepts JIDs. We’d prefer this to be more flexible i.e. searching by surname only displays the contact details in the same way as searching for contacts does.
These are deal-breakers for us - while the first is an annoyance to our users the second is very difficult to address. In the current Spark version (2.6.3) our users would need to know the login ID of every user they’d want to invite and as our login ID is AD-based authentication with the first 6 characters of the surname follwoing by one or two characters from the firstname this is asking a lot of our users.
What’s most depressing about the above post is that it was posted in 2007 and more than 5 years later they’ve had no reply
Now it has 2 replies Spark and Openfire (and other projects on this site) are not very active, there is no pro support or paid developers working on it, just a bunch of volunteers ocasionally doing something. So, these issues won’t be fixed soon or ever.
So, you are not using groups and your users have to search and add their contacts manually? Well, in my opinion this approach is not very user-friendly either. At my company i’m using shared groups and every user is getting all contacts automatically (grouped by departments). Then on the Start a conference tab they can press Roster button and select users they want to invite (sorted alphabetically by names). This can be complex with a huge roster and some search option would be handy. But there is only that JID option. I think this was done with JID (username), because few servers can be connected together and searching by username@servername is the better option to search for users on the other server. Anyway, i agree that Spark has flaws and many things should be fixed, but nobody is doing this. Developers are needed, or just patches for some issues. Then you can also use the nightly build with a particular patch included.
Thanks for the quick reply! I had assumed that there is no pro support or paid developers since it is a free product and wasn’t expecting a reply so soon.
We haven’t rolled out Spark/OpenFire to our users yet, just a bit of investigating by the sysadmins here so we haven’t been using groups. I hadn’t look at that as an alternative route to sending invitations to conferences but it’s a similar issue - if you do a search by e.g. surname, unless that surname is unique then the search results show a list of users who match that surname but unfortunately the list only shows the JID (in our case the login ID followed by our domain).
Since our login ID is based on the first 6 characters of a user’s surname and the first character of the first name. Frequently another character is added if a user with the same login ID already exists e.g. John Smith already has smithj then Jackie Smith would be given smithja.
Given the similarities between login IDs we wouldn’t expect users to know someone else’s login ID so when presented with a list of JIDs they wouldn’t know which one to choose. This is the same problem as mentioned above when looking for users to invite other users to a conference.
If the search facility in the conference area or the groups window provided the same information as the search bar at the bottom of the Spark window i.e. JID, username, Name e-mail columns then our users (and I unclude us sysadmins in this) would be able to use the Name column and possibly even the e-mail column to identify which user tehy want to invite to a conference or add to a group.
I appreciate this is likely to need reprogramming of the Spark interface so it was a shot in the dark asking if anyone knew how to get around this. Our company is looking to outsource e-mail and file documentation facilities (which we currently administer) to Google on the premise that Google also provide an AD integrated instant messenger for a low cost (we looked at MS Lync server but the CALs and client costs went into 6 figures for our company so that was ruled out). I was hoping that OpenFire and Spark were cheap alternatives to MS Lync and even Google Talk but it looks like that small but crucial search interface for conferences or adding users to groups rules it out
But many thanks for taking the time to reply to my post and to do so quickly
I hadn’t look at that as an alternative route to sending invitations to conferences but it’s a similar issue - if you do a search by e.g. surname, unless that surname is unique then the search results show a list of users who match that surname but unfortunately the list only shows the JID (in our case the login ID followed by our domain).
Not sure you understood this part correctly. What i ment is that our users get a whole roster, but not with the usernames (which in our case are in jsmith form), but they see normal names like:
-Managers group
John Doe
Peter Pan
-Personnel group
Ann Smith
John Smith
We don’t use AD, but this is possible to pull groups with users, share them in Openfire and all users should be showing in the roster with they full names. And then in the Start a conference dialog after pressing the Roster button one would see a list:
Ann Smith
John Doe
John Smith
Peter Pan
And would be able to select whom to invite to a conference.
If you don’t want to use groups, then yeah, there is no way to workaround this other than changing usernames to some readable form. And the search issue is there too. So yes, you should probably search for an alternative. Not sure when and who will fix anything here.