I am working on an Elgg installation where we will provide both *friends*functionality (reciprocal relationship requiring confirmation) and
*follower* functionality (one-way relationship, like the friends in Elgg
Core).

While the core already provides a predefined ACCESS_FRIENDS level, the
corresponding ACCESS_FOLLOWERS level needs to be implemented manually. "No
big deal", I thought initially, but as I sat down to write the code, I
realised that there is no provisioning in the API for checking the subject
of an access request (the user making the request) against the object (the
owner that we should be following to be granted access).

It appears to me that the only place where this is possible is the *
get_access_sql_suffix* function in *engine/lib/access.php*. Clearly I'd
rather stay away from modifying the core, but I think I don't really have a
way around it. Given the static nature of this access level (unlike the
Friends Collections that are created dynamically), I wouldn't want to
programmatically create an access collection for every user that is being
followed, though it seems that this is the only viable option in the API.
Am I right?

Having said all this, the question: do you think that it would make sense
for Elgg Core to offer both friends and followers as defined above? I'm
working on that at the moment, and would be happy to share the code, but
that would entail modifying parts of the core. If there is interest in
this, I would obviously design it differently to what my specific needs
require, so that - for example - one or both features could be disabled in
an installation to suit the admin's needs. Hence the question of whether
such a change would be welcome in the engine...

Federico

What about the 'permissions_check' plugin hooks?

On 8/23/12 2:28 PM, Federico Mestrone wrote:

Thanks for bringing this up in a careful and clear way. My first thought is that this may
be a bit difficult for users to understand, but setting this aside for now...

ACCESS_FRIENDS in the core is really "people you have followed" and I assume
ACCESS_FOLLOWERS would be "people who are following you". I definitely see some value in
the distinction. It's a bit like group-visible content in open groups (to see the content,
just join the group).

Or would you use a completely separate access list so that reciprocating followers would
not automatically be friends of each other?

This may actually be pretty easy: listen to relationship events for following, and update
the followed user's access list.

As much as I rail on about not modifying the core, as long as your development is firmly
on a git branch, you can be pretty safe for most upgrades via merge. But I didn't say that.

Beyond the code the biggest challenge would be UI and user education. Would it require
anything more than adding a new access level?

Steve
--
http://community.elgg.org/profile/steve_clay

Hi Steve,

Thank for your reply. I have actually completed work on this now, using a
couple of plugins I found and adding my own code to implement the
ACCESS_FOLLOWERS level. Even so, I think this could really be a useful
improvement to the way that Elgg views user relationships out of the box,
so I'm still thinking of ways to refactor code to make it more useful to
everyone.

This would be my vision... ;-) Elgg Core would offer two types of
relationship between users
1) "friend": a bidirectional relationship between two users that requires
confirmation (same as Facebook atm, different to current Elgg
implementation). This is a close relationship between two users, hence the
need for confirmation on both sides (the one making the request, and the
one accepting it).
2) "follower": a one-way relationship from one user ("follower") interested
in more information about the activities of another user (that they're
"following") (same as the current implementation of Elgg friends). This is
a distant relationship... Anyone can follow whoever they like with no need
for the other party to confirm or accept the relationship.
In terms of the access levels, in my implementation it leads to this, in
increasing order of breadth of scope
ACCESS_PRIVATE (0) - only the owner
ACCESS_FRIENDS (-2) - only the owner and friends (close relationship that
needs to be confirmed)
ACCESS_FOLLOWERS (-3) - the owner, their friends, and all followers (who
can follow regardless of the will of the owner)
ACCESS_LOGGED_IN (1) - everyone who is logged into Elgg
ACCESS_PUBLIC (2) - everyone
In between ACCESS_FRIENDS and ACCESS_FOLLOWERS currently sit the dynamic
Friends Collections.
As far as UI goes, there is a number of changes that are needed, to allow
users to keep track of pending friends requests (before acceptance by the
other party) and the list of followers. But I have already assembled some
code from two existing plug-ins that do the job. The only thing plugins
cannot do is access the ACCESS_FOLLOWERS level without creating new access
collections.
To crown it all, a number of settings would allow the admins to choose how
the new features should be used in their own installation. To avoid
confusion, for example, the basic installation should only enable followers
(exactly the same behaviour as the current version), with friends - in the
NEW sense of the word - available for enabling alongside followers or on
their own from the admin settings. Other options could be whether firends
should be included as part of the followers access level: in my case it is
and I think it makes sense, but there could be situations in which this is
not desired...

Anyway, I'll follow your suggestion and branch out of the core to make the
changes I have in mind. I think it's the best way for people to evaluate
whether it's a bunch of useful changes... and it's a great way for me to
learn more about this amazing platform ;-)

Fed

The more I think about this the clearer it becomes to me that Elgg's
friends are the equivalent of g+ circles. It's the terminology that is
confusing, but the design is sound. If we changed the terminology and made
friends collections more useful, people could treat different collections
as they please (e.g. easier to manage collection membership for a given
person, a page of activity from a particular collection). I would love to
have separate circles for the community site for "troublemakers" and
"potential core members" and be able to track the activities of each ;).

I would say that once you can share with just a certain subset of people
you circled, there is no need for "tight" friendship relationships.
Instead, you decide who to trust each time you post. How much you share is
what really determines the tightness.

Unless I'm missing something?

On Aug 23, 2012 2:53 PM, "Federico Mestrone" <fmestr...@gmail.com> wrote:

couple of plugins I found and adding my own code to implement the
ACCESS_FOLLOWERS level. Even so, I think this could really be a useful
improvement to the way that Elgg views user relationships out of the box,
so I'm still thinking of ways to refactor code to make it more useful to
everyone.
relationship between users
confirmation (same as Facebook atm, different to current Elgg
implementation). This is a close relationship between two users, hence the
need for confirmation on both sides (the one making the request, and the
one accepting it).
interested in more information about the activities of another user (that
they're "following") (same as the current implementation of Elgg friends).
This is a distant relationship... Anyone can follow whoever they like with
no need for the other party to confirm or accept the relationship.
increasing order of breadth of scope
needs to be confirmed)
can follow regardless of the will of the owner)
Friends Collections.
users to keep track of pending friends requests (before acceptance by the
other party) and the list of followers. But I have already assembled some
code from two existing plug-ins that do the job. The only thing plugins
cannot do is access the ACCESS_FOLLOWERS level without creating new access
collections.
how the new features should be used in their own installation. To avoid
confusion, for example, the basic installation should only enable followers
(exactly the same behaviour as the current version), with friends - in the
NEW sense of the word - available for enabling alongside followers or on
their own from the admin settings. Other options could be whether firends
should be included as part of the followers access level: in my case it is
and I think it makes sense, but there could be situations in which this is
not desired...
the changes I have in mind. I think it's the best way for people to
evaluate whether it's a bunch of useful changes... and it's a great way for
me to learn more about this amazing platform ;-)
/friends/ functionality
functionality (one-way
(to see the content,
being followed, though
following, and update
development is firmly

you know, I knew that - and every time I need to do something with
permissions I have to rediscover it.

On 8/24/12 3:51 AM, Evan Winslow wrote:

Totally. Getting the circle management UI right is the hardest part, and it needs to be
editable at any time.

Looking forward, if circles (now FCs) were implemented as ElggCollections, users could
choose to make some visible to others, and site and group admins could collectively own
circles attached to those entities. All UI work done to improve circles could benefit
collection mgmt and vise versa, etc.

I guess we're blessed that Elgg has such exciting paths available, but they sure all seem
hard!

Steve
--
http://community.elgg.org/profile/steve_clay

Two practical, attainable tasks here:

   1. Provide activity streams for friends collections in addition to the
   existing "Friends", "Me", and "All".
   2. Improve the UI for managing those collections (ajax!).

Are these trac-worthy?

Evan Winslow
http://community.elgg.org/profile/ewinslow