Thanks Dhrup!

Kane - if you wanted to report documentation errors to this group, I'll definitely see to it that they are fixed: http://community.elgg.org/pg/groups/20578/elgg-documentation/

@Cash - done and done :)

PS.  Is there really no way to "subscribe" to a group discussion thread?  It sucks having to manually keep checking if there was any responses.

Unfortunately, no. You can subscribe to an entire group but not individual threads. I have a version where the RSS feed is actually useful, but I haven't rolled that in to the core.

Darn, I thought I could trick the cron plugin by simulating a login, but that doesn't work either.  Even though $result = TRUE, when I call get_entities() it still doesn't return any that aren't public.

        $elgg_username = "admin";
        $elgg_password = "mypassword";
       
        // Login
        if ($user = authenticate($elgg_username,$elgg_password))
        {
            $result = login($user, false);
        }

I'm completely stumped...

More confusing things going on.  Related to still forcing the admin user to actually login within the cron script, as described above.

If I make sure I'm logged out of Elgg and load the /pg/cron/fiveminute/ URL in my browser and in the cron function if I do,

echo get_access_list();

I see (2,1)

If I refresh the page without doing anything else,

I see (2,1,0)

So apparently I have to run the cron script TWICE for it to actually know that the admin user has the correct access and only then I can get the entities that aren't public.

I also tried,

echo isadminloggedin();

And it returns TRUE every time, so is it possible that Elgg is just *slow*?  How could it know that an admin is logged in, yet the admin's access list doesn't include "0" (private)?

I'm guessing that this has something to do with Cookies...?

Found the solution - posted at the end of this thread - http://community.elgg.org/mod/groups/topicposts.php?topic=185245&group_guid=7

I needed to add a single line after the login() function:

admin_init();