[WIP] fix(db, api): update database model & API schemas

[vkWeb]

• I have read Chapter's contributing guidelines.
• My pull request has a descriptive title (not a vague title like Update README.md).
• My pull request targets the master branch of Chapter.

This is not ready for review. It's a work in progress. I am updating the database & API schemas to reflect the recent decisions we made:

• Allow multiple tags per event.
• Adding admin as a user role. So now we have three user roles: participants (normal visitors), organizers & admin(s).

Closes #254.

[vkWeb]

So here are the architectural updates we will make:

• add user_roles table for organizers and admins
• add routes for tags and events

cc @timmyichen @Zeko369 Is it fine?

[Zeko369]

Remove typeORM from here, this should be DB schema only

[vkWeb]

for user roles, how did you want to model this? i can imagine a world where a single user could be both a participant and an organizer, or both an organizer and an admin, etc.

@timmyichen we can create a user_roles table with id and type as string and reference can be made via users table?

[timmyichen]

👍 makes sense to me, just be sure to add a column for the chapter_id for user_roles since each of these roles are specific to a particular chapter/org

type might work better as an enum anyway depending on how typeORM handles those migrations cc @Zeko369

[Zeko369]

We can try using enums, but strings might be simpler and easier when it comes to migrations, not sure what you meant by how typeORM handles those migrations

[vkWeb]

@timmyichen Admin as a user role isn't related to any chapter Tim.

Let's discuss the API endpoints we should create.

[vkWeb]

@timmyichen Should we consider this:

GET /events
GET /events/{eventId}

Wouldn't the 2nd one be redundant as we already have chapters/chapterId/events/eventId?

My point is in the events page we need to show all the events irrespective of a chapter, right? Then how we will do that via the current api routes?

[timmyichen]

I think the only routes that are actually necessary are:

chapters/{chapterId}/events/{eventId}
chapters/{chapterId}/events

Anything else (like /events/{eventId}) would just be shorthand for the above and a bonus.

Regarding Chapter roles, I think an Admin user role is still necessary for deletion perms. You wouldn't want any organizer to also have the ability to delete/edit your Chapter (that power should be given to the creator by default only); organizers should only be able to manage events for the Chapter. Let me know your thoughts on this.

[Zeko369]

Agree, for now I think that c/e/:eID is enough

[vkWeb]

@Zeko369 @timmyichen

My point is in the events page we need to show all the events irrespective of a chapter, right? Then how we will do that via the current api routes?

[Zeko369]

Do we though? They're namespaced to chapters or am I wrong?

[vkWeb]

@Zeko369 They are namespaced to chapters. So in the events page we will loop over all the chapterIds and their respective event(s)?

[timmyichen]

@vkWeb That can be done via a route like /events, but I would not group it in with the same as /events/{eventId} since they would do very different things

[Zeko369]

We could then have
/events -> get all event across chapters (homepage)
/chapter/:id/events -> get chapter events (chapter homepage)?

[vkWeb]

@timmyichen Agreed.

So /events with just GET as a method? We won't be updating anything via this route, right?

For that we have chapters/... route.

[vkWeb]

We could then have
/events -> get all event across chapters (homepage)
/chapter/:id/events -> get chapter events (chapter homepage)
?

Perfect!

[vaibhavsingh97]

@vkWeb can you please update the PR with necessary changes as suggested in comments

[allella]

@vkWeb commented on Discord last week that he'd be unavailable for awhile. It may be best to reassign this one.

[vkWeb]

@vaibhavsingh97 as @allella mentioned I'll be inactive for a while :(

I have marked this PR ready for review so you all can push changes and merge them at your pace.

@ceciliaconsta3 would you like to tackle this?

[allella]

@Zeko369 @timmyichen @ceciliaconsta3 would you all be okay with reviewing and approving the earlier commits and then opening more specific PRs for the user_roles and API endpoint parts of this conversation.

This has been open for awhile and I could see it sitting and becoming a blocker if we expand the scope to include user roles and API endpoints.

I've reviewed the ddl.sql and the event_tags and tag schema changes look like a good start to me.

I'm not sure what the Swagger documentation is supposed to look like, so I can't comment on that one.

[allella]

@nik-john could you look at the Swagger file on this PR and see if it needs anything.

I'm thinking we commit the event tags and move the API routes and user roles comments to new or existing issues so we can close this and not have it lingering.

I've reviewed the schema changes and it looks simple enough to merge.

[QuincyLarson]

@nik-john Could you look at the changes to the Swagger file real quick before we merge this?