Schema: Add field(s) for video conference URL / Online Events

[allella]

@Zeko369 @timmyichen @QuincyLarson @tomiiide

One of actionable next steps was to update the schema, models, and API to handle online / virtual events.

The schema ER diagram may be a bit out of date, but I think it's current enough for this conversation.

Rough Ideas to Seed the Conversation

• add an optional events.video_url field specifically for a video conference / live stream URL. (issue Add video_url to Events table #380)
• add a events.url field specifically for a general event website / URL. In the application's logic, this could default to the event's public Chapter URL. An organizer could set / override this URL to point somewhere else. For instance, if the chapter is hosting a hack-a-thon / large event, then they may prefer to direct API traffic to a more general outside_events.url_ landing page. (issue Add event URL for each event #381)
• add the following fields to venues (street_address, city / locality, postal_code, region, country, latitude, longitude). Otherwise, events would be advertising to meet at a physical venue but the user may have no idea where to go. (previously added by Fran)
• we'll want a way to filter between physical and online events. The easiest way to do this would be to have an events.venue_type field with enumerated options {"physical", "online", "physical-and-online"}. It's possible we could infer whether an event is physical, online, or both without this field, but it would be more complex and subject to errors. Quincy mentioned a toggle in the UI for "Physical" vs "Online", but "Both" is just as likely to happen. We might as well ask the organizer to specify when an event is created and the UI could show/hide elements for a physical venue and/or online/video and we avoid the guesswork. (issue Add venue_type to events #382)
• remove postal_code from locations. A chapter like freeCodeCamp Greenville doesn't really have a "postal code". chapters and non-profits typically serve a broader locality or region so a physical zip code for a chapter is probably not of much value to a user. If we later develop a zip code radius search feature, then we could decide to add a postal code back, but I suspect we'd use a venue's postal code and not that of a chapter. (edit: I proposed we remove locations in a comment below) which was removed in Remove redux and migrate to Apollo on Admin Dashboard #394

Caveats

• As an alternative approach, I was considering that an event could have one or more venue records and these could house physical and/or online venue details. However, the fields used for physical and online venues would be potentially mutually exclusive and I felt we'd be cramming two concepts into one table. This may be a viable alternative with some better thinking.
• This doesn't exactly adhere to schema.org for Events and VirtualLocations but I did try to anchor the field names and rough idea to those schema.

[pdotsani]

If we're going with auth0, I think it might be helpful to save some parts of the user profile auth0 provides. This is what a successful auth0 request returns after login:

{
  "clientID": <id_here>,
  "created_at": "2020-07-21T03:15:58.770Z",
  "email": <email_here>,
  "email_verified": true,
  "family_name": <last_name>,
  "given_name": <first_name>
  "identities": [
    {
      "provider": "google-oauth2",
      "user_id": "<id_here>,
      "connection": "google-oauth2",
      "isSocial": true
    }
  ],
  "locale": "en",
  "name": "<first_name>,
  "nickname": <nickname_here>,
  "picture": <url_here>,
  "updated_at": "2020-07-21T03:15:58.770Z",
  "user_id": <id_here>,
  "sub": <id_here>
}

Another benefit of using auth0 is that we wouldn't have to save passwords anymore.

[allella]

@pdotsani I don't think the schema has been given much consideration for the auth fields, so it's rather likely we need more work on that side. In fact, if the social_provider and social_provider_users tables don't make sense in the context of using only Google Auth, then we can trim down the schema there too.

Since this issue is primarily focused with the virtual events vs physical events, could you create a new issue or PR and share thoughts on schema updates for required users fields?

[allella]

@timmyichen @Zeko369 thoughts on the proposed adds / changes to the schema for handling online meetings?

[Zeko369]

Yeah, we're definitely going to be removing social_providers for now and only keeping the google auth.

I'll open up small issues so more people can work on this stuff.

add an optional events.video_url field specifically for a video conference / live stream URL. #380
👍

The URL thing is a great idea. #381
Chapter -> URL
Event URL -> if missing use ChapterURL

add the following fields to venues (street_address, city / locality, postal_code, region, country, latitude, longitude). Otherwise, events would be advertising to meet at a physical venue but the user may have no idea where to go.
Shouldn't this just be a link between locations and events? @allella what do you think?

Enums for online/offline events #382

Remove postal_codes #383

[allella]

@Zeko369 I don't think I was involved in the initial locations or venues to know the reasoning.

It looks like locations was created to allow for a city / region / country search like was mocked up for the main Chapter instance landing page.

However, the schema also shows a relationship between venues and locations, which would only make sense if locations had a street address, lat, long, and zip code as well.

I don't think we need both tables. If we move city, region, country to the chapters table, then it allows for something like SELECT * FROM chapters GROUP BY city, region, country to easily populate the values for a city, region, country search.

Then, venues could have their own street_address, city / locality, postal_code, region, country, latitude, longitude as described earlier, and we don't need locations.

Does that make sense? Mixing a physical venue address and a generic location is what we had. It's two different use cases and we can accomplish both use cases with only chapters and venues.

[allella]

As further support to remove the locations table, here's more ways it would be confusing.

Physical venues need a street address, latitude, longitude, and zip code. In the current form, this would require us to add street address, latitude, longitude, and zip code to locations.

chapters typically do not have a physical street address because they are often just meetup groups and not physical organizations.

chapters often change venues or meet at different venues, so it could further confuse a member / attendee if a chapter presented a physical address because that chapter's events will often be at an entirely different physical venue address.

It's just confusing to have both chapters and venues mixed together in a single table when those tables can hold the values needed for their own use case.

[Zeko369]

@allella Since most self hosted chapter instances will only have one chapter I completely agree with you that we should remove location aspects of chapter entities in the db. Since we'll only have locations in one place (venues) and since most of the time venues won't share locations, we can move the columns needed for location to venues and remove locations all together

[allella]

I think we can still have a city, region, country on the chapters table because groups like freeCodeCamp are likely going to have many chapters and having those fields connected directly to each chapter's record will allow for any easy front-end query by city + region + country, as in the Figma mockup

[Zeko369]

Agreed, let's do it that way then @allella

[allella]

@Zeko369 I'm closing this discussion since you created issues for the tasks and since #383 handled the largest part of the changes. Thanks

[allella]

All the pieces of this issue should now be covered thanks to @katien