What to use for access_id on "backend" (non-content) ElggObjects?
By Steve Clay
I sometimes have a need for "backend" objects that don't provide user-facing content, aren't registered for search, and shouldn't be associated with any particular user. E.g. tasks in a task queue that runs on cron.
Is it safe to give these objects access_id = ACCESS_PUBLIC (instead of ACCESS_PRIVATE)?
This eliminates the need for wrapping elgg_set_ignore_access() around queries, but it makes me think Elgg might expose these in some way.
Thoughts on using ElggObjects on generic backend storage (not as "content")?
Plugin Development
Talking about how to write plugins
- Steve Clay@steve_clay
Steve Clay - 0 likes
- Matt Beckett@Beck24
Matt Beckett - 0 likes
- Evan Winslow@ewinslow
Evan Winslow - 0 likes
- Jeroen Dalsem@jdalsem
Jeroen Dalsem - 0 likes
You must log in to post replies.Another example: Access-Plus uses public objects to persist data associated with custom managed access collections.
It would be nice if we could create just generic ElggEntities - not necessarily ElggObjects, as in most cases for this all we need is to store some metadata and a relationship or something. No need for title/description and population of the objects table.
One issue with this is that these entities show up in all of the statistics, and if they're ACCESS_PUBLIC can be exposed with the generic object view: [url]/view/[guid]
It's best to assume Elgg will expose them in some way.
Because Elgg exposes public entities very easily ([url]/view/[guid]) i suggest using private entities for this purpose at the moment.