annotation and access set to friends (or friend collection)


I have just experienced some strange access things regarding annotations on a entity (blog, etc.).

User A creates a blog, setting access to friends only.

User B comments on that blog. Comment gets an access of friends only

User C wants to read comments, but is not friend with B, so he/she can only read the blog, not see comment given by User B. User C gives a comment, which then can only be read by User A and and him self, not B.

I can see from the code, that annotations allway inherit the access_id of the entity they belong to. That must give some issues when using anything else than public!

A fix could be to allways set annotations to public access, and then make sure they are only shown to those who have access to the entity they belong to.

Anyone has some input on this, or should it go to bug tracker?

  • In my view the idea of allowing annotations and metadata to have access levels is a significant design flaw in Elgg. I believe that annotations and metadata should be accessible if and only if the user has access to the entity they are attached to. I believe that non-entity access levels were added so that profile fields can be metadata but still have independent access controls, but this makes the whole Elgg API more complex than it should be.

    But water under the bridge.

    In this case, I think that the problem could be solved by interpreting friends access for annotations and metadata as relative to the owner of the entity and not the owner of the annotation or metadata item. I'm surprised it was not done that way, and if not, it is probably a bug.

    So it should probably go in the tracker.

  • Hi Kevin

    I put the issue in tracker. Thx for your response.

  • Hi Kevin,

    thanx for your post. In my opinion you are totally right.
    In theorie the flexibility of access levels in elgg is fine, but in practice it is sometimes quite confusing or even makes no sense!

  • what is about the access_id of the river?
    it's confusing for the user, wenn he sets an entity to 'privat' in the widget
    and corresponding entries are still seen in the river . . . 
    it makes sense, then even new entities with new access-level are shown on the river
    but the user expected, that the access-level in the river works like in the widget
    for user it's a 'error' and touches his privacy when corresponding entries to an entity
    are still seen in the river

    i think the access_id in the river table is obsolete,
    but i can imagine that it could be a peformance-problem to join to actual access_id of the entity,
    so it could be a solution: when user changes the access-level of an entity, an update query runs over the river table (because this can also make performance-problems you could ask the user if he want to change the access-level for all new entries or change also the old entries)

  • As a very dirty workaround. In /engine/lib/views.php around line 766

    elgg_set_ignore_access(TRUE); // override acces on annotations

    $annotations = trigger_plugin_hook('entity:annotate', $entity_type,


    'entity' => $entity, 'full' => $full,



    elgg_set_ignore_access(FALSE); // Stop override acces on annotations

    This should only affect access to annotations if you have access to the entity they belong to.

  • @slyhne it's not dirty ;-)) for me, it's the 'interim-solution' till it's handled with a sql-query :-)
    the approach is right, the entity the annotation belong to, is the master and triggers the access to the annotation

    thanks a lot

    @interestedmembers for elgg 1.8 search function 'elgg_view_entity_annotations' and change code like @slyhne shows above

  • an other approach:

    look at page/components/list.php
    elgg_view_list_item($item, $vars) displays the items of the activity/* pages
    what do you think about?:

    foreach . . . .
    if ($item->access_id == get_the_accessID_of_the_entity-type_from_widget_settings_of_the_user(){
    $html .= elgg_view_list_item($item, $vars);}

    this assumes that the user triggers the visibility of his data with the access permissions for the widget-content on his profil-page and i think, this what the user expects
    if a entity is saved the access_id comes from the widget permission (e.g. thewire) or is explicit set in the form (e. g. Blog)

    what do you think?