[This spec is in progress and not finalized. I am sharing my thoughts here]

We need to first deprecate TempOrgRedirectso that no new type of redirects are added to it. We need to provide an alternative better way for this.

Why Deprecate?

As the name suggests, TempOrgRedirect was supposed to be temporary when we were migrating people manually to organization. The purpose was to allow old link to keep on working by redirecting visitors to organization link for the same user.

Problem with TempOrgRedirect schema

• It uses RedirectType enum but only uses RedirectType.User and RedirectType.Team AFAIK. The reason is simply that it is only supposed to handle a user migration and not event migration(there is nothing like event migration. So, RedirectType.UserEventTypeand RedirectType.TeamEventTypecan be removed.
• It doesn't have a relation with User. So, if the user is deleted, we have to handle the cleanup in user deletion. I am not sure if that is implemented.
• It doesn't have a relation with Team. So, if the team is disbanded, we have to handle the cleanup in team disbanding. I am not sure if that is implemented.
• It has fromOrgId because we thought it could be used to allow redirect from one organization to other. But it is always set to 0 which means it handles redirects from non-org only.
• It has absolute URL in tofield which means that if the organization slug changes, all to's need to be updated.

Need for more generic Redirect schema

Need for redirect could arise due to following reasons

• User got added to an organization - The reason why TempOrgRedirect was created
• User got removed and there is a replacement for that user who will handle all their events - Being handled through TempOrgRedirect
• User is OOO and someone else will step in - Handled through OutOfOfficeEntry

When loading a booking page, we should be able to decide the redirect ASAP and it would be better if all redirects are added at a single place so that table lookup is needed. Also, conflicting redirects across table isn't easy to maintain. e.g. How about a case where User1 has an OOO entry for User2 and User2 is now removed from the organization. It could be easier to get a picture of redirect through a single table.

This doesn't mean that OutOfOfficeEntry table is replaced. Maybe, OutOfOfficeEntry table shouldn't be used to decide redirect. The redirect entry for it could be in the new Redirect table.

Maybe 2 Redirects table

• UserRedirect
• TeamRedirect

Having two different tables would make the lookups faster as a team(link) doesn't care about user and vice versa

_{From SyncLinear.com | CAL-3972}