Cron access override best practice

I'm writing a plugin that would gather usage statistics from Elgg on a daily basis. I want to know how many registered users there are and how many logins were made each day, among other things. I was planning to make this easily extendable so that it would be possible for plugin developers, for instance, to log the daily number of searches or something similar.

Obviously, this plugin relies heavily on the cron functionality and I have question related to overriding the access settings. The idea was to have the daily cron to create a special entity, where the number of any events would be saved as metadata. I wanted to set the access_id of the entity to ACCESS_LOGGED_IN, but then, of course, the cron cannot find the entity.

Is the best solution to use elgg_set_ignore_access() in the cron? What's the best practice here? It's a powerful function and I'm scared something bad might happen :) Does this approach even make sense overall? Should the entity be public so the cron can find it without any access tweaks? Any other ideas how to handle this or any comments on the functionality?

Any input highly appreciated! :)

  • You could use something like SimpleBrowser to login to the site before running an action.

    You can track Javascript events in Google Analytics, so you could potentially track any kind of activity (for JS users) on the site that way.

     

  • elgg_set_ignore_access() was created to be used in cron like this.  It's usage is missing in the wiki--I swore I had written a page on it--but you'll want to do something like this:

    ...in cron hook function...

    elgg_set_ignore_access(TRUE);

    generate_stats();

    save_entities();

    elgg_set_ignore_access(FALSE);

    There's also a section in the wiki about the permissions check hook, which can be used to override write permission (canEdit()) on an entity, but can't be used to show entities that you don't have access to (access_id = ACCESS_LOGGED_IN when not logged in).

  • I'm confused why this relies on cron.  Why not just do queries against Elgg's log table?

  • The systemlog tables are regularly rotated, so I assumed it was for caching counts and trends over certain periods to be available after rotation.

  • @Steve, That sound like an interesting approach! I'll look into it, but I think this time I'll do this inside Elgg.

    @Brett, thanks for the reply! That's axactly what I had in mind, but I just wanted to make sure that's the best way to do it.

    @Evan, Brett got it right. I want to be able to show statistics how the number of users and logins has increased in the last year, for example. That old data won't be available through the logs if logrotating is enabled.