ACLpopulateSR - Automatic Addition of Users to a Shared Roster Group

Name: ACLpopulateSR
Purpose: Allows automated addition of users to a Shared Roster Group
Author: Badlop
Type: Patch
Requirements: ejabberd 1.1.4
Download: mod_shared_roster.erl.diff

Important: If you just want a Shared Roster Group to contain all the users on the current virtual host, ejabberd supports that feature since SVN revision 413 (2005/09/29). Read more about this subject here.

Purpose: 
This patch adds a new option to ejabberd.cfg -> modules
You can specify users or pattern for users names to be automatically
added to a Shared Roster Group at server start.
New accounts are also checked to be added to the group. 

A) PATCH:
	1. Copy mod_shared_roster.erl.diff to your ejabberd/src
	2. Apply the patch with: patch -p0 <mod_shared_roster.erl.diff
	3. Recompile ejabberd 

B) EXAMPLE CONFIGURATION:
	4 Create a Shared Roster Group called 'devels'. Name: 'Devs', Displayed: 'devels'.
	5 On the 'modules' section in ejabberd.cfg, replace
			{mod_shared_roster, []},
		with:
			{mod_shared_roster, [{add_acl, {sr_devs, "devels", "myserver"}}]},
		where:
			- sr_devs is an 'accessname' (check the ejabberd guide)
			- devels: name of the shared_roster_group
			- myserver: is the server name (or virtual host) of the shared_roster
	6 On ejabberd.cfg add 'access' lines to define the users in the roster:
		{access, sr_devs, [{allow, admin}]}.    % Add the server admins

	{access, sr_devs, [{allow, all}]}.      % Add all the users

	{acl, badlops, {user_glob, "badlop*"}}.
	{access, sr_devs, [{allow, badlops}]}.  % Add all the users named badlop*

C) TRY IT
	7. Now that ejabberd is compiled and configured, restart ejabberd. 
	8. Go to the webadmin and check that the 'devels' group has the users.
	9. Login with any user and check he receives the shared roster group.
	10. Register a new account and check it is added to the group.
Changelog:
9/November/2007: Second release:
 - Updated to ejabberd 1.1.4 (thanks to Syka)
 - Added support for multiple groups.

4/August/2005: First release, for ejabberd 0.9.8

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

q

q

how this contribution works with ejabberd 1.1.2

Is this mod working with ejabber 1.1.2 or it was only a contribution for ejabberd 0.9.8??

If it was a contribution only for ejabberd 0.9.8, how we can make the same functionality in later ejabberd editions.

Thanks

Not tested with 1.1.x

syka wrote:

Is this mod

This is a patch for mod_shared_roster. This is not a new module.

syka wrote:

working with ejabberd 1.1.2 or it was only a contribution for ejabberd 0.9.8??

It was developed for 0.9.8. Did you check if it still applies and works with 1.1.2?

syka wrote:

If it was a contribution only for ejabberd 0.9.8, how we can make the same functionality in later ejabberd editions.

I thought that functionality was not much required, since ejabberd 1.1.x has support for @all@. Do you think this patch provides an interesting feature today?

how many groups

I have a question. This path for mod_shared_roster in original version was suppose to serve only one group in shared roster? is it possible to add to this functionality to many groups, like:

{mod_shared_roster, [{add_acl, {sr_devs, "Clients", "example.com"}},
{add_acl, {sr_devs, "zCustomers","other.com"}}]},

with:
{acl, customers, {user_glob, "cus*", "example.com"}}.
{access, sr_devs, [{allow, customers}]}.

The point is to add the same group of users to the shared roster groups on different vhosts. I'm trying to add this functionality because shared roster works only within one vhost. I have group of users on 2nd vhost which have to be visible on 1st vhost. The group is huge this is why manual adding doesn't make sense.
Any ideas ??

I have the same query, want

I have the same query, want to add some groups but in different hosts. I spend a lot doing this manually.

This is because I'm handling more and more groups everyday. Please anyone knows??

Regards,
Locke

Simple change to allow several ADD_ACL

I wrote a simple change in the patch. Note that I didn't try it, in fact I didn't check if it compiles:

Replace this old code:

    case gen_mod:get_opt(add_acl, Opts, none) of
        {Access, Group, Server} -> 
            ejabberd_hooks:add(roster_get, Host, ?MODULE, add_acl, 65),
	    add_acl_start(Host, Access, Group, Server);
        _ -> ok
    end,

with this new code:

    case gen_mod:get_opt(add_acl, Opts, none) of
        {Access, Group, Server} -> 
            ejabberd_hooks:add(roster_get, Host, ?MODULE, add_acl, 65),
	    add_acl_start(Host, Access, Group, Server);
        List_AGS when is_list(List_AGS) -> 
            ejabberd_hooks:add(roster_get, Host, ?MODULE, add_acl, 65),
            [add_acl_start(Host, Access, Group, Server) || {Access, Group, Server} <- List_AGS];
        _ -> ok
    end,

With this change, add_acl accepts either a tuple or a list of tuples. For example, now this is also valid:

{mod_shared_roster, [
  {add_acl, 
    [
      {sr_devs, "Clients", "example.com"}, 
      {sr_devs, "zCustomers","other.com"}
    ]
  }
]},

This is similar to what you wanted. Please remember that I didn't try it at all.

Let's hope it works. If you finally get all working, consider publishing the code here :)

RE: Simple change to allow several ADD_ACL

Hi,

WELL DONE!!! This way we can add all specific users to specific shared roster group.

With the new code we can configure ejabberd.cfg like:

{acl, customers, {user_glob, "cus*", "example.com"}}.
{access, sr_devs, [{allow, customers}]}. % Add all the users named cus*

{acl, sale, {user_glob, "sal*", "other.com"}}.
{access, sr_sal, [{allow, sale}]}.

{mod_shared_roster, [{add_acl,[
{sr_devs, "Customers", "example.com"},
{sr_devs, "Clients", "other.com"},
{sr_sal, "Sales", "example.com"},
{sr_sal, "Sales", "other"}]}]},

Users with specific uid = cus* from host example.com will be added to shared roster group Customers on vhost example.com and to group Clients on vhost other.com. Similarly it works with users with user name sal*.

Here is the code with my changes:

mod_shared_roster.erl

Best
Syka

Thanks, patch updated

syka wrote:

Here is the code with my changes:
mod_shared_roster.erl

Thanks. I've merged your changes, my improvement, rebuilt the patch for ejabberd 1.1.4 and updated the download page.

Re: Not tested with 1.1.x

Yes i tried with ejabberd 1.1.2. The patch doesn't work, so i modified mod_shared_roster.erl file according to the patch, made some changes, compile it and exchange with actual module. It works, but additionally cause problems with <pressence>, i'm working on it.

I found this functionality very useful. We have few groups in shared roster, most of them with not many users so we can add them easly, but one is big with more than 100 users. Adding manually all the users to that group is not funny. So if we set:

{acl, customers, {user_glob, "cus*", "example.com"}}.
{access, sr_devs, [{allow, customers}]}.

and

  {mod_shared_roster, [{add_acl, {sr_devs, "Customers", "example.com"}}]},

than every user whith JID starting with 'cus' on 'example.com' serwer, will be added to that group.
But as i said, it has some bug, and i'm trying to figure that out.

Would be great if in web admin in shared roster option, during setting users for specific group, global options like '*' or '?' (ex: *cus*.example.com) would be available. That's a tip for the next version of ejabberd.

By the way. Ejabberd rulessss!!!!!!!!! :))

Idea: using vCard data to populate groups automatically

It would be nice if users gets automatically in the shared group they want if they edit their vCard. Examples:

  1. The admin creates the groups 'managers' and 'workers'.
  2. He selects in the web interface from a drop-down box 'Based on role' and adds 'manager' for the group 'managers', and 'worker' for the group 'workers'.
  3. If now managers change their vCard so that it contains '<ROLE>manager</ROLE>' (see JEP-0054) and for workers, '<ROLE>worker</ROLE>', they will be automatically added to the right groups.
  4. Managers can now chat with all other managers, and workers with all workers.

The same can be done with the vCard element '<ORGUNIT/>'. E.g., '<ORGUNIT>marketing</ORGUNIT>' to get all members of the marketing unit in the same group. Remark that people can get by using vCard data in different groups very easy and they can easy move between groups. E.g. if a manager moves to another unit, he can easily get to the new shared roster group, while still being able to chat with other managers. Other cool example:
A manager that moves to another unit:
<ORGNAME>IBM</ORGNAME>
<ORGUNIT>EMEA</ORGUNIT>
<ORGUNIT>marketing</ORGUNIT>

Later:
<ORGNAME>IBM</ORGNAME>
<ORGUNIT>AP</ORGUNIT>
<ORGUNIT>marketing</ORGUNIT>

--
sander

I'll be more than happy to see the code

I'll be more than happy to test and review such code when IBM, other big corporation or anybody else with enought free time implements it for their particular interests and releases it as Free Software, like we do.

Syndicate content