Improved visibility/privacy workflow

[boonebgorges]

The privacy setup should be as follows:

• Any event associated with at least one private group is private ("Private" meaning that no one can see it but members of associated groups)
• All other events are public

I think it should already work this way, but if it doesn't, it should be fixed :) See #5

We should have clear visuals when creating/editing events that indicate something to the effect of "You are creating a public event", which would change to private dynamically when associating with a private group.

@r-a-y This will probably mean sending back group status data as part of the Select2 implementation. Could you have a first look?

[r-a-y]

So I've kind of went over multiple revisions of toggling the visibility so it would make sense for the user.

I've now arrived at hiding the "Status" and "Visibility" options when a group is added to an event. I think this makes the most sense.

Here's a GIF showing how visibility is toggled when a group is added to (and removed from) an event:

Let me know what you think.

[boonebgorges]

I like it.

On 05/04/15 19:26, r-a-y wrote:

So I've kind of went over multiple revisions of toggling the visibility
so it would make sense for the user.

I've now arrived at hiding the "Status" and "Visibility" options when a
group is added to an event. I think this makes the most sense.

Here's a GIF showing how visibility is toggled when a group is added to
(and removed from) an event:

GIF
https://cloud.githubusercontent.com/assets/505921/7464680/e1827b5a-f279-11e4-9bad-e920a58eef8b.gif

Let me know what you think.

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

[r-a-y]

Closing out this one as this was addressed awhile ago.