OK. If you would be so kind as to confirm my concept.
I am testing Openfire for implementing in our company organization. I’m needing to have quite a few groups and some of the users will be in several groups.
I have my team leads that will also need to be in groups of their underlings (which are complised of a couple groups each). This should work and each group should see each other but the Team Lead group is not to be shared with their underlings. So I don’t allow the Team Lead group to be shared with the sub groups. This works fine as it should.
Now all of the underlings and Team Leads groups are all part of a larger group called Analysts. I don’t want Analysts that are not grouped into one of the underling groups to be able to see another user in another underling group so I should use the Packet Filtering to block Presence and Messages within the Analysts group (got this info from another post - answered by wroot).
But I also will have a Management group that will need to broadcast and see the entire Analysts group. I don’t however want the Analysts to see the Management group. How do I block this as sharing contacts goes both ways. Can I setup a Packet Filter that will block Analysts from seeing the Management group? Will Management still be able to talk to the Analysts groups without issue?
Any info would be great.
It would be nice to see some implementation of one way contact sharing in a future release of Openfire. I could see it being very useful for the high ups to be able to contact a lower lifeform without worrying about the lower lifeforms pestering the executives.
I think this should be possible to achieve with the Packet Filter rule. Action: Drop, Type: Presence, From: Group, Source Group: Managers, To: Group, Destination Group: Analysts.
Though Packet Filter won’t hide users if you enable sharing. So Analysts will see Managers. They will jsut appear as offline to them. But after a while they can find out, that you can still message managers even if they appear as offline. So, no real solution here.
So I’d be better off just dropping the idea to have the collection type groups and deal with the smaller sets only.
I might then look into setting up the higher ups to have access to the Openfire interface to use the message to all users.
To the Devs for Openfire… please see it in your machanical hearts to add the ability to customise the broadcast list for groups or allow contacts to be shared only one way. Or an individual developer could make a plugin.Maybe if I learn Java I might take up some sort of project.
Thanks Jedi Master Wroot. I’ll head back to the drawing board on my groups and rooms arrangment.
Well, one side sharing is a bit against XMPP standards. In XMPP you can chat and see status only if you are authorized by another person. Of course group sharing or subscription plugin (which automatically accepts subscription requests) are not by standards, so a plugin is always an option. But this seems rather complex. You want analysts not being able to see or chat on their own with the managers, and on the other side managers should see all and should be able to start a chat with the analysts, and then analysts should be able to reply (and only then i suppose). Oh, i think you should start learining Java Seriously, we don’t have too many active developers here, even for the more trivial stuff to fix. Or maybe you can hire some Java programmer for this.
It’s not so much keeping employees from chatting with management as much as allowing sub-groups within a larger group and keeping the larger group from see everyone else.
Say you have a group called EMPLOYEES and with in that groups you have all of your departments (Accounting, Sales, Management, Reasearchers… etc). You want the EMPOLYEES group to be messagable by the HR department (they are also in the EMPLOYEES group) such as a broadcast message. but you don’t want the other sub groups in the EMPLOYEES group to see other sub groups. So Sales won’t be chatting with Reasearchers.
Something like that would be great. As for Java learning… it’s on my list with about 5 other languages to learn before I die… I have a feeling it will be closer to when I die rather than tomorrow
I’ve been testing this with a small group of users at work before we roll this out. I think I found a work around on one way shared lists.
Create group 1 and set to share contacts. Say call them IT.
Create group 2 and do not share contacts but add everyone from IT group into this group as well. Lets call them Overseers.
Create group 3 and share them with Overseers.
This allows Overseers to see group 3 members in the contacts list but group 3 will not have Overseers in thier contact list.
This doesn’t keep group 3 from adding users from group 2 into the contact list but it does keep them from starting out with them in the contacts list.
So if you use the method described in my previous post and lock out adding goroups and users in Spark it should allow management or HR or whoever to see Everybody and send messages to them, but keep the minions from contacting or seeing user that they shouldn’t.
I’ll confirm this with some good ole testing… and this works, some what.
The HR group can indeed see the Minions groups and send messages/broadcasts to them. The Minions however cannot respond as the HR user shows as offline to the Minions.
Search is disabled as well as adding users to the Minions contacts list (from within Spark). So sould I do some wizardry with the Packet Filter to allow messages to HR from the Minions as long as the contact was initiated by HR.
So HR whats to know why Minion #5 didn’t clock out yesterday. So HR sends message to Minion #5 and says “What up wit’ dat?”. Minion #5 should be able to respond to HR in the window that came up but not add them to thier contacts list. I’m hoping this is also a task that can be done.
I’ll play with it a bit and report back.