Typically, all data in Elgg has inbuilt access information attached to it. This little piece of information, along with the enabled/disabled flag, determines to a great extent if you can actually access a piece of data and change it.
Knowing the different ways in which these combinations can work can make a developer's life much easier.
This a hack in the core itself, but one that you can't do without. This will enable you to access entities that have been disabled. Users, when they are not fully registered (email not verified), will be marked as disabled by Elgg, if you need your internal functions to access these entities, this method comes in pretty handy. Do keep an eye out for future Elgg releases, the team has specifically asked not to use this code in plugins, so use it at your own risk.
2. Get/List all entities
There are times when you would want non-admin users to access bits of data stored within Elgg's data model. This is also valid in cases where you want to list data that is not owned by you. Most of the front end usage won't require this, but there are situations where this is required like a heavily moderated website where it makes sense. In those situations, you can set $is_admin to TRUE for the duration of the get/list entity call and reset it to whatever the original status was.
$astat = TRUE;
$astat = FALSE;
$is_admin = true;
#your get/list calls
$is_admin = $astat
Do use this very wisely as you don't want regular users running around on the site with full admin privileges.
Permissions check allows you to write to entities that you don't have permissions to access. Kind of beats the whole purpose, right? But there are cases where this is very much valid, like in case of objects that are to be shared between restricted set of users. Again, this is a function that should be used with a lot of care and cross checked for contexts and conditions in which it is allowed to operate.