We are using Wildfire 3.0.0 Release with Psi 0.10 connected to an Windows 2003 Active Directory. Presence is still not working. Whats funny is if I log into the server on 2 machines using the same account, one on my Mac and the other on my Windows box the presence works between the windows and mac box. I used Psi’'s XML console to monitor data and had other users go on and offline and there was nothing sent from the server to the client.
Anyone seen this yet? This was also broken in 2.6.2
This is a huge problem for me, also.
It really prevents me from migrating to domain-authenticated logins. Because, frankly, there’'s no point.
In order to provide a positive user experience for the users at my company; the whole point of using Wildfire is so that users can login and see (in their mind) a pre-populated buddy list. We don’'t want an experience where a user logs in, and not being “seen” by everyone else.
So, sadly, right now I’‘m manually creating the logins. Pain in the @$$, but at least I can control they they are properly added to the ‘‘everyone’’ group. Some may wonder why I at least use the domain authentication-- I don’'t want users to be able to login without me properly setting them up first.
I sincerely hope this gets fixed…
(otherwise, we all love Wildfire!!!)
Just an update. I created JM-744 for this issue and already narrowed down the problem. Will try to fix it during the weekend or early next week.
JM-744 and JM-745 are fixed now. You can use the next nightly build (the Monday build) to test how things work now.
For some reason I can’'t pull up the thread referenced in JM-744 (500 Servlet Exception).
Does that bug have anything to do with commas in the cn/name attributes in LDAP? I can confirm that the released 3.0 build still has this presence problem as well.
Not sure why you are getting the error 500 when trying to access http://www.jivesoftware.org/issues/browse/JM-744. In any case, the jira issue is just a description of the problem: “Presence updates are not being sent to shared contacts whose subscriptions is FROM.”.
As you can see this problem is not related to the comma issue in cn/name attributes in LDAP. And yes, Wildfire 3.0 has this problem as well as Wildfire 2.6.2 and previous versions. The bug fix is now available in the nightly build version that belongs to the future Wildfire 3.0.1 release.
Hope that helps.
Thanks! Seems like a lot of people are working today!
Do you know if the issue I mention is an open issue? I’‘ve looked through the Open Issues and was unable to find anything that looked close. I did notice someone a while back mentioning the same problem I am having in the forums. As far as I can tell, Wildfire isn’‘t throwing any exceptions, it’'s just not sending the change out to the clients (for these users that have a comma in the cn/name).
I’'ve tried monday nightly build and presence is not sent :(. Active Directory Groups and logins are used and all users have subscription ‘‘to’’. When user changes his status a presence message is sent to server:
But users who did not subscribe for presence do not receive any info.
If user subcribes to other he can see status changes and sees his subscription type as ‘‘both’’. If AD groups are not used just logins all users has subscription as ‘‘both’’ by default.
And my questions: Is this a normal behaviour or bug?
If it is bug can I expect solution in 3.0.1 release?
If it is normal maybe it would be usefull to add a setting like “grant presence” in admin console as a group property?
And my questions: Is this a normal behaviour or bug?
Any user will only receive presence updates from contacts it is subscribed to.
I agree with jancio. Seems like if we tell the server to display a group to other users then they should be notified of presense without having to subscribe to that user.
I consider it broken because when a user first goes online they get thier list of groups and users in those groups. The client displays users who are currently online with whatever icon they use to display a user is online. But if one of these users go offline everyone elses client still shows them as being online even though they are not. I think if users are configured to show up in clients rosters then they should automatically get presence updates. It wouldnt make since not to and have users still showing online when they arent.
I also tried the Monday build and it still appears to be broken.
I agree with you that things should work fine. Could you provide me a step by step on how to configure the server and steps to follow to reproduce this problem? BTW, the nightly build version already fixed 3 or 4 shared group presence issues. Seems that there is still one more hanging around.
I am wondering if any workaround for the presence problem is available. I looked at database table ‘‘jiveroster’’. If a bit more details is available on that table I can test some temporary solutions so we can survive until final solution. By more details I mean how Wildfire is dealing with the table (and of course if it makes sense at all to change it).
“The bug fix is now available in the nightly build version that belongs to the future Wildfire 3.0.1 release.”
How can we get hold of the 3.0.1 release to test the fixes that have gone into it? We are affected by JM-695. Our user cn’'s have forward slashes which prevent them logging in, and commas which prevent presence updates from working. We need both of these isues fixed before we can deploy Wildfire. Both issues are part of JM-695.
Ahhhh… JM-695! I was beginning to think this bug wasn’'t being worked on. Thanks for the reply to this thread parseljc! (I guess my searching abilities for these bugs is less than good.)
I am in the same situation. This bug (JM-695) is holding up a deployment for us as well. I totally misunderstood Gato when he said it was in 3.0.1. It’‘s good news it’'s fixed somewhere.
I guess I’‘ll just wait for the release…already been waiting, what’'s a few more weeks?
We have our Wildfire server connected to our Win2k3 Active Directory using the following search and group filters.
This configuration didnt work in any version previous to 3.0. It now works correctly and displays all the correct users and groups as it should. The presence was a problem in very early 2.x versions that caused us to have to take the system offline until it was fixed.
We are using Psi 0.10 client for both OS X and Windows. When we log in all users who are currently online show up as being online. However, if one of theses users ever go offline nothing changes and no XML message is sent to any of the currently connected clients. If I login using my account on one box then log in using the same account on another machine and start going on or offline it is sending the XML messages to the other machine where I am logged in. But not to other users. I hope this helps, if you need more let me know.
Message was edited by: dombiak_gaston
Thanks for the update. Could you try using the latest nightly build that includes many fixes to shared groups? Let me know how it goes. BTW, I have been trying to reproduce JM-695 using openLDAP and things are looking good so far. I would be interested to hear if you were running into that issue when using Wildfire 2.* and not anymore after Wildfire 3.0 or latest nightly build.
I tested the latest nightly build and it still has the presence problem. I have not had a problem (JM-695) with authentication and our users CN’‘s have comma’'s in them such as “cn=Smith, Joe”. Never had an authentication problem only presence problems when using LDAP.
JM-695 is not about authentication but about presence problem when using commas in CNs. Could you try removing the commas from some users and see if that helps. If it works after that change then I would like to get in contact with you by IM so I can analyze and fix this problem. So far I’'ve been trying to reproduce it using OpenLDAP and it worked fine.
I just fixed an issue that was generating the presence problem when username contained “invalid” characters. The problem affects those setups where username contains the server name. The bug fix has been checked in and will be available in the next nightly build. Since I’‘m not able to reproduce the problem I’'m not sure if this is the only problem we have. Could you try again using the latest nightly build? For people using Wildfire 3.0.0 you will only need to replace the existing wildfire.jar with the new one included in the nightly build version.
If the problem still persists then I will ask you to enable the debug log and post in this thread the messages that you have.