You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 2, 2021. It is now read-only.
In order to reuse the site every year without clearing out Application's table
every time we need the concept of an event.
Event should be a straightforward model to implement. It will need a name (and
probably a slug, although how that will be utilized is best left to another
issue), a date range for accepting applications, and possibly a cutoff date for
early bird applications (I'm not sure if this will be used for anything
functional, but it's a piece of data we've displayed in the past). We'll
probably need additional fields in the future (e.g., an identifier from the
registration service to create discount codes and/or tickets), but we'll worry
about that when we know who and what that will be.
Event should be registered as a foreign key on Application. In order to ease
the migration, a default event should be created and associated with any
existing applications.
Another nice-to-have would be a way to get the "current" Event when one hasn't
been explicitly specified. Initially maybe this can just be the one created by
the migration; down the road it can look at the dates.
The text was updated successfully, but these errors were encountered:
In order to reuse the site every year without clearing out
Application
's tableevery time we need the concept of an event.
Event
should be a straightforward model to implement. It will need a name (andprobably a slug, although how that will be utilized is best left to another
issue), a date range for accepting applications, and possibly a cutoff date for
early bird applications (I'm not sure if this will be used for anything
functional, but it's a piece of data we've displayed in the past). We'll
probably need additional fields in the future (e.g., an identifier from the
registration service to create discount codes and/or tickets), but we'll worry
about that when we know who and what that will be.
Event
should be registered as a foreign key onApplication
. In order to easethe migration, a default event should be created and associated with any
existing applications.
Another nice-to-have would be a way to get the "current"
Event
when one hasn'tbeen explicitly specified. Initially maybe this can just be the one created by
the migration; down the road it can look at the dates.
The text was updated successfully, but these errors were encountered: