We have moved to Github. Please open tickets there.

Opened 20 months ago

Last modified 13 months ago

#3872 new Feature Request

Make backend ACL implementation more flexible

Reported by: ewinslow Owned by:
Priority: normal Milestone: Long Term Discussion
Component: Core Version: 1.7
Severity: minor Keywords:
Cc: brett@… Difficulty:

Description (last modified by ewinslow)

The access control system could use a makeover, don't you think?

Right now Elgg supports:

  • Private
  • Friends
  • Logged in
  • Public
  • Custom ACL (whether a group, friends collection, etc.)

What Elgg does not support:

  • All my friends and Tom (unions)
  • Everyone except Tom (exceptions)
  • Friends and friends of friends (extended friends)

I think the easiest way to get this kind of flexibility would be to leverage relationships.

General approach:

  • Track which users and groups of users been given explicit permission and/or have been explicitly denied permission via relationships (as opposed to tracking users that have been implicitly given permission by being a part of a special group -- public, logged in, extended friends, friends).
  • Cache the result of the explicit unions/exclusions in a DB table any time these permissions are changed to keep access checks fast.
  • Users blocked from seeing a piece of content cannot see it even if they are a member of a group that has explicitly been given permission.
  • Users/groups that have been explicitly given permission to view may view even if they are not part of the "base" access collection that was selected (e.g. public, logged in, extended friends, friends, private).

Of course, we'd also have to improve the UI to be capable of reflecting these options.

Change History (1)

comment:1 Changed 13 months ago by ewinslow

  • Description modified (diff)
  • Milestone changed from Needs Review to Long Term Discussion
Note: See TracTickets for help on using tickets.