[Issue #3874] Create Rough Tables for Opportunity Applicate package

[babebe]

Summary

Fixes #{3874}

Time to review: 15 mins

Rough Tables Created
opportunity_application_form
opportunity_competition_form
opportunity_competition
opportunity_competition_assistance_listing
opportunity_competition_instruction

Factories created

[mdragon]

We should think through the lifecycle a bit more than just currently active or inactive. Do we need to have a "available after"/"available until" kind of dates when a form is "depreciated" or "retired?" For example what if SF-424 v4 is live now and v5 gets approved and added to the system. Do all applications switch immediately? Do new application packages only show v5 when selecting what forms to add? Is there a period where both remain pick-able when setting up an application package? Even if we just have active, I think it'd be good to have this be a date/time and have it be called like inactive_at and that date then controls if it's shown and also provides more of a history of when it became inactivated, can be set for a future date, etc.

If we want to move this forward in the short term, maybe just make this a timestamp instead of boolean and re-name it accordingly and then we can always add an "active_at" column in the future if we need more specifics of a lifecycle.

[babebe]

@mdragon These were initially considered basic columns, with the plan to add more as needed. I believe it's a good idea to include both inactive_at and active_at columns, as it's generally better for each column to serve a single purpose rather than combining logic. Thoughts?

[mdragon]

I think that makes sense for now and then yes, we absolutely shouldn't try to make perfect tables out of the gate and anticipate revisions and improvements as we work with the tables and learn more about the functionality. 👍🏻

[babebe]

Added inactive_at -nullable and active_at-non-nullable datetime columns and updated factory

[mdragon]

I would maybe let active_at be null too for now. I could see someone setting up a form but not knowing when it will be ready to be made active and so we'd force them to put in some random future date to be able to even start working on the form. I think it being null is a better signal that it's not scheduled to be active yet.

[babebe]

Should we then update is_active to default to False or be nullable ?

[mdragon]

Sorry, I thought we were replacing is_active with the active_at. I think we can just remove is_active for now and we can use a active_at <= now() kind of logic to determine if something is active rather than having the boolean too.

[babebe]

removed is_active and made active_at nullable