Shared groups are not visible in members' rosters

Hey ho buddies!

I’m working on the integration of Openfire with a web system that uses

a MySQL DB to keep users’ info. I’ve integrated the auth, users’ info

and groups following the instructions available on the Custom Database

Integration Guide. That works like a charm! BUT when I log into

Openfire using Spark I can’t see the groups of the user! I took a look

at previous posts related to this issue and I figured out that in order

to make groups available on members’ rosters it’s necessary to set

“Enable contact list group sharing” in the Contact List (Roster)

Sharing box of the Edit Group area of the Admin Console. But in this

very box it’s written: "By default, this

group will only appear in the contact lists of the group’s members.".

So, as far as I could understand, if “bbking” is a member of the

BluesGroup group, whenever I log in as “bbking” this group must be on

my roster even if the “Enable contact list group sharing” is not

set, since “bbking” is a MEMBER and BY DEFAULT the group will appear in

the contact lists of the group’s members. Or I misunderstood the

sentence?

Is there a way to make this “default” behavior really “default”?

Thanks a lot!!!

This sentence is in the Contact List (Roster) Sharing box, so it speaks about sharing behaviors. This is the default behavior of Enabled roster sharing. There would be no sense if sharing would be working without even enabling it. Moreover, a group can show up in roster if display name is set, in Openfire. And you cant set it without enabling roster sharing.

Hi dmadruga,

I’ve bugged the Openfire devels about this very issue a number of times. I can’t seem to find the forum post about it currently. The “By default” is very misleading and I wish they would reword it. I have to educate new openfire admins every time of this quirk

daryl

Edit: Aha, found it: http://www.igniterealtime.org/community/thread/27513

Hey wroot and akrherz, thanks for answering!

uhh… I really think this sentence is not suitable to be where it is.

But anyway… Is there a way to make groups show up in their members’ rosters by default. I’m talking about more than 500 groups, so if the sysadmin has to set this flag for each one, and even worst, for every new group created, it will be a pain in his @$$!

Thanks!!!

I agree that that message can be more clarified, though it has never missleaded me (and i dont recall anyone else complaining in forums).

dramadruga, server software cant be adjusted for any specific scenario, which yours is. Some sysadmin wouldnt need automatical sharing of groups, so one will have to go to every group and uncheck that checkbox.

Developers, of course can create some option in server setup pages, to turn on groups sharing automaticly for all created and existing groups automaticly. But group sharing is not a xmpp/jabber standard, this is a custom openfore feature, so probably they dont want to make it a default. Another problem could be because of current architecture. As i said, shared group need Display name. And you can set it only in group properties. So you still have to go to group properties after you have created it. Also you have to go to group properties to fill it with users. 500 times, if you have created 500 groups

Another option could be a page with groups list and checkboxes “Share it” near them. So you could select only groups (or “check All”) you want to enable sharing. But what to do with Display name? Maybe it could set a Display name the same as group’s name automaticly.

Personally i have groups named shortly and based on functionality, departments etc. (e.g. man_sales_1floor). And Display name could be “Managers/Sales Managers - 1st floor” (this will look as nested group “Sales Managers - 1st floor” in “Managers” group in Exodus). I dont want groups to show up in groups list with such complex long names. Especially if i use nesting.

So, it’s easy to change the description. But everything else is more complicated than it can look like.

Hey wroot, I appreciate your support!

Whether the sentence is clear or not… Well… We’ve got different

opinions. But that’s ok. Now I understand what they mean

Now I’m trying to come up with a little hack to make the system work as

I want. The first and most simple solution I thought about was writing

the necessary info to openfire’s DB. It works fine for porting my

current database, but I realize that it doesn’t work very well on the

fly, because Openfire seems to keep a cache of the group status (in

memory or in disk?) and it doesn’t ‘echo’ DB changes unless I restart

it. Once I saw a post about that, and I remember the guy figured out

how to shorten the cache flush time. But I just can’t find this post

anymore And maybe this would cause a severe lack of performance…

I’m also wondering if I can use openfire’s API to perform this

operation, since it works fine when I do it through the admin console.

I’m investigating… But if anyone has the answer… please!

BTW: wroot, do you have any link to help me finding info on nested groups? I’d love to use this feature!!!

Thanks!!!

Ok!!! I found a solution:

I’ll keep my mapping (from my DB to Openfire groups) then I’ll use a plugin called Helga (http://www.igniterealtime.org/community/docs/DOC-1080) to configure the groups on the fly. I’ve just tested it and works fine.

:smiley:

Daniel Madruga.

Glad for you. As about nesting, i dont recall any documentation about this (maybe it2000 have described it in some of his documents about Spark, try searching in community). Nesting can be set while setting your group’s name. With shared groups that would be a display name. Some clients support nesting, so they use special symbol to separate nested parts. Exodus uses “/” (can be changed) by default. So, if you specify name “Test/Support” (without quotations) for a shared group, in Exodus you’ll see virtual group Test and Support group as a part or Test. With Spark you should use " :: " (without quotations, but with spaces) as a delimiter. But nesting in Spark is a bit broken:

http://www.igniterealtime.org/community/thread/24858?tstart=50