help! create_event_listener for a subtype messes up access rights...

 

Using elgg 1.5

We have a special arrangement, in that we have a 'group' plugin which we use for 'projects', and a 'dgroup' plugin which we use for groups. Basically two copies of the same plugin.

All was working fine, until I discovered a 'small' bug in our code: the dgroup plugin was never working for access collections, the key was always empty.

I figured out the problem was:

register_elgg_event_handler('create', 'dgroup', 'dgroups_create_event_listener');

this function takes the event and the object type as parameters - no subtype, so in this case the listener never got called.

I tried to solve the problem this way:

register_elgg_event_handler('create', 'group', 'dgroups_create_event_listener');

and in the dgroups_create_event_listener:

$dgroup_subtype = get_subtype_id('group','dgroup');
            if ($object->subtype != $dgroup_subtype)
                return true;
               
            $dgroup_id = create_access_collection(elgg_echo('dgroups:dgroup') . ": " . $object->name);
            if ($dgroup_id)
            {
                 $object->dgroup_acl = $dgroup_id;
            }
            else
                return false;
      
        return true

That seemed to work fine, but now the riverdashboard doesn't work: every call to

get_entities_from_metadata

seems to fail, and page constructions fails, giving me a half-baked page.

Any suggestions? Highly appreciated!!!

 

EDIT: The problem needs to be related as when I comment out the call to the event handler registration

//register_elgg_event_handler('create', 'group', 'dgroups_create_event_listener')

the riverdashboard turns to work fine...

  • Can you check the PHP or apache error log for any errors?  It sounds like PHP is stopping execution because of a fatal error.

  • Fablo, how do you use dgroup_acl?  I suppose you want additional access control for your dgroup, above what the stock Elgg group provides.  In that case you probably have some plugin hook for permission check.  I suspect that the meta data search identifies a dgroup that the user has no access to according to dgroup_acl.

  • Sorry guys, was working with different branches and got confused.

    The problem was not at all there. I override the input/acces view, because as we have dgroups and groups, the drop-downs for access were always displaying both "group:xxxx" and "project:xxxx" (coming from the dgroup and group respectively) - when in fact in a specific page, it can be only the one OR the other.

    I put in this code in my input/access view (sorry for length):

    /* line 40 */ foreach($vars['options'] as $key => $option) {

    $page_owner = page_owner_entity();       
           
            if ($page_owner)
            {
                $type = page_owner_entity()->getSubtype();
                $start = substr($option,0,strlen($type));
               
                //if the option starts with project or dgroup
                if ( (stristr($option,'project') ) || (stristr($option,'group')) )
                {
                   
                    //if it's a group, we don't need the project access list
                    //if it's a project, we don't need the group access list
                    if ( strcasecmp($start, $type))
                        continue;
                }
            }

    it looks like a terrible hack but it works, it seems...my problem was that in the page which was breaking, page_owner_entity()->getSubtype(); didn't return a valid page_owner_entity and thus the call to ->getSubtype failed.

    If you see some obvious misconception here or have any other suggestion, you're most welcome.

     

     

  • Instead of changing input/access.php, you could also try to use the 'access:collections:write' hook.  You would notice that input/access.php calls get_write_access_array() when the list of access groups is not provided through $vars['options'].  The 'access:collections:write' hooks are called by get_write_access_array() to customize the access group list.  So I suppose one of your plugins can do the filtering.

    Note that the groups plugin attaches group ACLs to the access group list precisely through this hook.  You may choose to change the code there (and presumably in your dgroup) to be more discreet, thus avoiding filtering later.

    Yet do you expect page owner entity to be null?  If not, you may want to look into it further.  It may cause you other problems down the road.  A plugin can call add_page_owner_handler() to make custom page owner available.

    I also remember you had problem with "group:guid" in URL.  I wonder whether you use "dgroup:guid" or just "group:guid" for your dgoup's name.  I am not sure if it is necessary to override the name format.

  • @PLai,

    I'd say your comment hits the nail on the head. I hope to be able to try it out soon...but as usual, other critical bugs around, so leaving the working horse to be checked later :)