Testing now.  Thanks!

The updated version of Roles works!

Works great! Thanx

This fixed my isssue!  Thanks!

Hi Andras,

As I helped you clear a bug, I would hope you could help me clear a low basic problem.

I have read you manual, and used your "menu permission" example in the config.php file of the roles plugin:

        DEFAULT_ROLE => array(
            'title' => 'roles:role:DEFAULT_ROLE',
            'extends' => array(),
            'permissions' => array(
                'actions' => array(
                ),
                'menus' => array(
                    'site::members' => array('rule' => 'deny'),
                ),
                'views' => array(
                ),
                'hooks' => array(
                ),
            ),
        ),

Allthought it seem like I have done as the manual says, I still se the Members link in my menu.

• I have tried to place the Roles plugin at the top and the bottom of the plugins.
• I have changede the part as you have explained in your comments for $updated_menu
• I have deactivated hypeframework and phloor framework (thought they maybe conflicted)

But still no result.. Could another plugin conflict with Roles?

@TheMuller:

• If you're also using the Group Admin for Roles plugin, you should change the DEFAULT_ROLE config in mod/roles_group_admins/start.php (as it overrides the roles plugin default configuration)
• After changing the configuration array, make sure you visit any page ony your site as admin. This is necessary for the changes to take effect.
• Now log out from your admin user, and log in as a non-admin member. The Members menu item should not be present any more in the menu. Please note that the DEFAULT_ROLE only applies to non-admin members, so as an admin you'll still have the Members menu.

If still no luck, I really don't know what could be wrong with your particular installation.

Thank for replying so quickly.

• Ah, roles_group_admins. If several plugins override the DEFAULT_ROLE (let's just say with no overlapping rules). Would rules work parallel to each other? And what if the rules were overlapping?
• By "visit any page" you mean the page that is made a rule on?
• Of course.. :) And it worked for me, thanks..

But.. How do I find out, what the names on site, page, actions are..? Like members

Example: Blogs.

I am able to deny the access to the page: blog/all. Defined like blog/all in persmission arraypages.

But I am not able to deny access to the menu, tried: site::blog/all, blog, blogs, even tried to use page::blog.. etc. Still visible in the non-admin member menu.

        DEFAULT_ROLE => array(
            'title' => 'roles:role:DEFAULT_ROLE',
            'extends' => array(),
            'permissions' => array(
                'actions' => array(
                ),

                'pages' => array(

                     'blog/all' => array('rule' => 'deny'),  //works great! 
                ), 
                'menus' => array(
                    'site::members' => array('rule' => 'deny'), //works great!

                    'site::blog/all' => array('rule' => 'deny'), //does not work
                ),
                'views' => array(
                ),
                'hooks' => array(
                ),
            ),
        )

Hope you have the time to answer these questions. As soon as I get the hang of it, I will try to add all this information to your manual, for others to use. With your counter check of course.. :)

@TheMuller

"If several plugins override the DEFAULT_ROLE .... Would rules work parallel to each other?"

Depends on how the specific role plugin author implements the configuration hook. Rules can be merged or overwritten, this is a design decision of the author.

"But.. How do I find out, what the names on site, page, actions are..?"

As I stated in the documentation, this is a plugin for elgg developers, and is rather a framework than a full-featured plugin. So if you want to implement your own roles, you'll have to learn php and Elgg - there is no easy workaround, I'm sorry.

For your specific menu issue, try 'site::blog' => array('rule' => 'deny'). But again, you'll have to have an understanding on how the Elgg menu system works. Elgg has great documentation, which will help you sort out most of your generic questions.

I get "roles" plugin installed but didn't see where to change things as docs said at admin interface, this should be done hard coding or trough the admin side of ELGG?

Check the folder "docs" in the downloaded roles plugin on your pc. There is a PDF file with a manual..

to hide the notice on the plugin on roles.php line #510 add to the if condition  array_key_exists('context', $permission_details)  

Notice: Undefined offset: 1

to hide/fix  in start.php line #200 instead of 

list($menu_name, $item_name) = explode('::', $menu);

put

$splittedArray=explode('::', $menu);

if (count($splittedArray)>1)

list($menu_name, $item_name)=$splittedArray;

else {

list($menu_name)=$splittedArray[0];

}

@Shahar thanks for your fixes. You could put these on github as a pull request for the role project at https://github.com/arckinteractive/Roles

Your name would be listed among the contributors for the next release.

Can a role be set for who which member types show up on a Google map or not? Please help.

Can-Do ! ;-)  You will need to (just;) define the appropriate roles configuration code.

Something along these lines :-

(1)
The default to DENY general access to your google map view:=

    DEFAULT_ROLE => array(
        'title' => 'roles:role:DEFAULT_ROLE',
            'extends' => array(),
            'permissions' => array(
                 'views' => array(
                    '<tahoe_billy_google_map_view_path>' => array('rule' => 'deny'),
                ),
            ),
        );

(2)
The role-specific to ALLOW roles-driven access to your google map view:=
    $ROLES = array(
        ’google_map_users_type’ => array(
            'title' => 'yoursitename_roles:google_map_users_title',
            'permissions' => array(
                 'views' => array(
                    '<tahoe_billy_google_map_view_path>' => array('rule' => 'allow'),
                ),
            )
        );
    );

Where <tahoe_billy_google_map_view_path> is the  path for
the view on your install/ plugin which serves your google map stuff.

<tahoe_billy_google_map_view_path>

Dhrup, I don't want to block a member type from viewing the map, I want to block a member type from appearing on the map. I want to collect theor address info, which normally places all member types on the map. I want 2 of the 3 types to NOT appear as icons on the map, and then later, maybe have others maps they might appear on. Firstly, I need them to not appear on the main map.

Is this what you suggested, or was this blocking a member type from viewing the entire map?

@ALL: i found out that Andras is mia wrt this plugin and s-o-o i gonna 'takeover' for some enhancements, tweaks, ui stuff and kindred i've been mulling over. if *any person/s have ideas, thoughts and want to be considered, lemme know so.

embed-extender.1.8.3

@tattergreis That should be enough, no additional configuration is required.

@ Andras THX :) works like a charm

Hello,

Terrific job; I love this plugin However, I couldn't get it to work. The reason, I suspect, was because the roles_get_roles_from_config plugin hook is defined in the start.php while you initially create role from config in activate.php. Therefore, there is no default role created when the plugin is activated because elgg loads start.php after plugin activation, so the hook to generate roles in start.php doesn't take any effect on activate.php. Moving elgg_register_plugin_hook_handler('roles:config', 'role', 'roles_get_roles_config') from start.php to activate.php does the trick.

I've made a pull request in github. Hope that you can look into it soon.

Thanks a bunch,

Lim.

@Lim thanks for your comment and contribution. I'll have a look at your pull request soon - I can do it probably early next week. Will get back to you. Cheers, Andras

@andras: simple fix - the elgg_register_plugin_hook_handler() in activate is called before the start's hander (actual) code is defined - just needs (a) move (or?)  copy into activate.. 2.5 lines affected only ;)

@Dhrup moving the code block is definitely not advised, as then the auto-update mechanism after configuration array changes will not work any more. It might be only 2 lines, but has many implications, so I'd like to test this properly before pulling in the code.

oki ;) tho -- since activate is already danging without the hook handler code available..? if copy the hook def`n in there - it will execute.. *once -- unless your activate's code comment
  // Not sure if it's a good decision to automatically delete existing roles
was put there by you for good foresight and reasoning !?
in which case might be a good idea to re-visit the validity of that whole logic @there anway.. probably can be incorporated into start.php with relevant referential verification(s).Mifht as take the timing to patch any loose algorithmic strucs.