Post level access control

[AbdealiLoKo]

@Phoenix25 The post level is_public thing is not enough..

What we need is something like this :

On the right corner, make a dropdown box.
When clicked, it gives something like :

Access rights : (for person who created or to whose wall it is)

• Let all users see this post
• Only members of this wall + tagged members can see this post
• Only members of this wall can see this post
• Only tagged members can see this post
• I don't want to see this (remove user from accessing this post)
  Notifications :
• Notify me of any further updates related to this post (if already notified, give option to de-notify)

Now, when we do this ... all access rights filters will change. Make a new branch. This will take quite a lot of testing to figure out.

[Phoenix25]

Hmm. No 4 Only tagged people can see them? That.. is counter-productive and
confusing no? if people belonging to the given wall can't see what's going
on.
Considering No.1, No.2 & No.3, i can stack them as the domains continuously
increase form 3 to 1
Nos 5 & 6 are a completely different thing. i check for access and then
make another option for them to unsubscribe/subscrbe.

On Sat, May 31, 2014 at 4:15 AM, AbdealiJK [email protected] wrote:

@Phoenix25 https://github.com/Phoenix25 The post level is_public thing
is not enough..

What we need is something like this :

On the right corner, make a dropdown box.
When clicked, it gives something like :

Access rights : (for person who created or to whose wall it is)

• Let all users see this post
• Only members of this wall + tagged members can see this post
• Only members of this wall can see this post
• Only tagged members can see this post
• I don't want to see this (remove user from accessing this post)
  Notifications :
• Notify me of any further updates related to this post (if already
  notified, give option to de-notify)

Now, when we do this ... all access rights filters will change. Make a new
branch. This will take quite a lot of testing to figure out.

—
Reply to this email directly or view it on GitHub
#89.

[AbdealiLoKo]

If I want to speak to spons core about server deal I'm not supposed to let
everyone in spons team nor WebOps team know.

i think it's required.

yeah, I know you can stack. Basically we need to make 4 different queries
and OR it with another field.
Regarding the field. Do not use is_public, rather use acces_level and make
a choice field. It's more flexible

On Sat, May 31, 2014 at 11:52 AM, Sai Praveen B [email protected]
wrote:

Hmm. No 4 Only tagged people can see them? That.. is counter-productive
and
confusing no? if people belonging to the given wall can't see what's going
on.
Considering No.1, No.2 & No.3, i can stack them as the domains
continuously
increase form 3 to 1
Nos 5 & 6 are a completely different thing. i check for access and then
make another option for them to unsubscribe/subscrbe.

On Sat, May 31, 2014 at 4:15 AM, AbdealiJK [email protected]
wrote:

@Phoenix25 https://github.com/Phoenix25 The post level is_public
thing
is not enough..

What we need is something like this :

On the right corner, make a dropdown box.
When clicked, it gives something like :

Access rights : (for person who created or to whose wall it is)

• Let all users see this post
• Only members of this wall + tagged members can see this post
• Only members of this wall can see this post
• Only tagged members can see this post
• I don't want to see this (remove user from accessing this post)
  Notifications :
• Notify me of any further updates related to this post (if already
  notified, give option to de-notify)

Now, when we do this ... all access rights filters will change. Make a
new
branch. This will take quite a lot of testing to figure out.

Reply to this email directly or view it on GitHub
#89.

Reply to this email directly or view it on GitHub
#89 (comment)
.

[Phoenix25]

then you post on his wall and select only people of this wall should see
this. OR you post on the core wall.

On Sat, May 31, 2014 at 11:55 AM, AbdealiJK [email protected]
wrote:

If I want to speak to spons core about server deal I'm not supposed to let
everyone in spons team nor WebOps team know.

i think it's required.

yeah, I know you can stack. Basically we need to make 4 different queries
and OR it with another field.
Regarding the field. Do not use is_public, rather use acces_level and make
a choice field. It's more flexible

On Sat, May 31, 2014 at 11:52 AM, Sai Praveen B [email protected]
wrote:

Hmm. No 4 Only tagged people can see them? That.. is counter-productive
and
confusing no? if people belonging to the given wall can't see what's
going
on.
Considering No.1, No.2 & No.3, i can stack them as the domains
continuously
increase form 3 to 1
Nos 5 & 6 are a completely different thing. i check for access and then
make another option for them to unsubscribe/subscrbe.

On Sat, May 31, 2014 at 4:15 AM, AbdealiJK [email protected]
wrote:

@Phoenix25 https://github.com/Phoenix25 The post level is_public

thing

is not enough..

What we need is something like this :

On the right corner, make a dropdown box.
When clicked, it gives something like :

Access rights : (for person who created or to whose wall it is)

• Let all users see this post
• Only members of this wall + tagged members can see this post
• Only members of this wall can see this post
• Only tagged members can see this post
• I don't want to see this (remove user from accessing this post)
  Notifications :
• Notify me of any further updates related to this post (if already

notified, give option to de-notify)

Now, when we do this ... all access rights filters will change. Make a
new
branch. This will take quite a lot of testing to figure out.

Reply to this email directly or view it on GitHub
#89.

Reply to this email directly or view it on GitHub
<
#89 (comment)

.

—
Reply to this email directly or view it on GitHub
#89 (comment)
.

[Phoenix25]

Also, the access_level might become inapplicable here as there is no clear
'level'. u go from full public to private+tagged to private (this has a
notion of level) but then u go to tagged a different domain than the last
one. atleast you couldn't call it a level. it's more a specifier..

On Sat, May 31, 2014 at 11:58 AM, Saipraveen Bangaru <
[email protected]> wrote:

then you post on his wall and select only people of this wall should see
this. OR you post on the core wall.

On Sat, May 31, 2014 at 11:55 AM, AbdealiJK [email protected]
wrote:

If I want to speak to spons core about server deal I'm not supposed to let
everyone in spons team nor WebOps team know.

i think it's required.

yeah, I know you can stack. Basically we need to make 4 different queries
and OR it with another field.
Regarding the field. Do not use is_public, rather use acces_level and make
a choice field. It's more flexible

On Sat, May 31, 2014 at 11:52 AM, Sai Praveen B <[email protected]

wrote:

Hmm. No 4 Only tagged people can see them? That.. is counter-productive
and
confusing no? if people belonging to the given wall can't see what's
going
on.
Considering No.1, No.2 & No.3, i can stack them as the domains
continuously
increase form 3 to 1
Nos 5 & 6 are a completely different thing. i check for access and then
make another option for them to unsubscribe/subscrbe.

On Sat, May 31, 2014 at 4:15 AM, AbdealiJK [email protected]
wrote:

@Phoenix25 https://github.com/Phoenix25 The post level is_public

thing

is not enough..

What we need is something like this :

On the right corner, make a dropdown box.
When clicked, it gives something like :

Access rights : (for person who created or to whose wall it is)

• Let all users see this post
• Only members of this wall + tagged members can see this post
• Only members of this wall can see this post
• Only tagged members can see this post
• I don't want to see this (remove user from accessing this post)
  Notifications :
• Notify me of any further updates related to this post (if already

notified, give option to de-notify)

Now, when we do this ... all access rights filters will change. Make a
new
branch. This will take quite a lot of testing to figure out.

Reply to this email directly or view it on GitHub
#89.

Reply to this email directly or view it on GitHub
<
#89 (comment)

.

—
Reply to this email directly or view it on GitHub
#89 (comment)
.

[AbdealiLoKo]

Also, add a link saying "Check who else can see this post"
We'll give a simple list of everyone who sees it.

Merge from Isseu #91