Open AbdealiLoKo opened 10 years ago
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 notifications@github.com 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 https://github.com/The-WebOps-Club/fest-api/issues/89.
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 notifications@github.com 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 notifications@github.com 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 https://github.com/The-WebOps-Club/fest-api/issues/89.
Reply to this email directly or view it on GitHub https://github.com/The-WebOps-Club/fest-api/issues/89#issuecomment-44719231 .
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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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 https://github.com/The-WebOps-Club/fest-api/issues/89.
Reply to this email directly or view it on GitHub < https://github.com/The-WebOps-Club/fest-api/issues/89#issuecomment-44719231
.
— Reply to this email directly or view it on GitHub https://github.com/The-WebOps-Club/fest-api/issues/89#issuecomment-44719266 .
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 < saipraveenb25@gmail.com> 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 notifications@github.com 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 <notifications@github.com
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 notifications@github.com 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 https://github.com/The-WebOps-Club/fest-api/issues/89.
Reply to this email directly or view it on GitHub < https://github.com/The-WebOps-Club/fest-api/issues/89#issuecomment-44719231
.
— Reply to this email directly or view it on GitHub https://github.com/The-WebOps-Club/fest-api/issues/89#issuecomment-44719266 .
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
@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)
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.