This line allows me to publish shared groups from my LDAP directory.
It also prohibits my users from creating local groups in their rosters. I shouldn’'t say it prohibits them from actually creating a local group, per se. Rather, it allows them to create the group and move people into it. When the user logs out then back in, the local group with everybody in it they just created completely disappears.
Commenting out the LdapGroupProvider line in wildfire.xml allows my users to create local groups in their rosters and put other LDAP users into those groups and preserves the changes during logoff/logon. It also prevents me from publishing shared groups in rosters.
I have tested this exact scenario on fresh installs of Wildfire 2.4.4 and Spark 1.1.0 on 3 different machines and the result is always the same.
So, a summary of what I’'ve done to confirm this issue:
Install Wildfire 2.4.4 and Spark 1.1.0 - don’'t enable LDAP at this time.
Create users and groups in Spark. Moving users into locally created groups works fine. Logging out then back into Spark retains all roster changes. Everything is good.
Configure Wildfire to use LDAP. Don’'t enable LdapGroupProvider at this time.
Add LDAP users to roster in Spark. Create local groups in roster. Move LDAP users to local groups in roster. Log out of Spark then back into it. All roster changes are retained. Everything is good.
Enable LdapGroupProvider via wildfire.xml.
Add LDAP users to roster in Spark. Create local groups in roster. Move LDAP users to local group in roster. Log out of Spark then back into it. All roster changes pertaining to the local group creation are gone. The groups are gone. The users in the groups are gone. Not good.
I have confirmed this on 3 different machines with 3 different fresh installations of Wildfire and Spark. Please, please, please fix this.
I think that once you have let the LDAP to handle group share, wildfire is not even looking back the group share. Since wildfire only do ‘‘read only’’ and never write back to the LDAP, you will always lose your groups which user created. But on second thought, the user is creating the group on the client side so may be the client can save the roster locally also.
Wildfire won’'t write back to LDAP for data integrity sake. Can you ask the question in the spark forum because I think that this is client side issue and they can come up with some answer for you.
well your clients could add those users as personal contacts, create their own group, and then move those “personal” contacts into those groups. When pulling groups from LDAP, in theory, a client should not be able to change the users in those groups as the Admin push that config down from the server. Remeber, these are active directory groups with define users from active directory. If you are trying to change the users that are display in your IM client, means you are trying to change which groups those active directory users are members of. This should never be allowed…
you might want to experiment with creating groups on the wildfire server instead of pulling them from LDAP.
This same behavior occurs with “personal” contacts as well as “shared” LDAP contacts. As long as LdapGroupProvider is enabled, creating personal groups and putting either LDAP users or personal users into those personal groups results in them being lost after a logoff and login. Disabling LdapGroupProvider solves the issue. Try it in a test environment. You’'ll see.
I have almost 10,000 employees in my organization. Not all of those users are on chat mind you, but not employing LDAP groups is simply not an option.
just tested it… it does wipe out any locally created group except for the default “contacts” and replaces it with the ones pushed down from the server.
Any chance you can test this under Wildfire 2.5? We made several fixes to the LDAP group implementation and I’‘d like to see if that solves this problem too. If not, I’‘ll file a bug and we’'ll look to get this issue fixed promptly.