[Design Discussion]: module scheduling architecture for the new module management UI (#3854 + #2895)

[imran-techvoyager]

Hey @willgearty , Following up on the discussions in #3854 and #2895 , I've been tracing through the module and deadline system to understand what a clean implementation of module scheduling would require, and a few design questions came up that seem worth discussing before implementation starts.

A few observations from reading through the code:

• ProgramModuleObj currently has no concept of time windows. Adding start_date / end_date fields (similar to the ExpirableModel pattern used by Permission and StudentRegistration) seems like a natural first step.
• There’s a caching subtlety around getModules_cached(): invalidation is triggered by DB writes, not time passage. This suggests time-based filtering may need to happen outside the cache layer (for example inside getModules()), rather than inside the cache layer itself.
• The relationship between modules and their corresponding Permission / deadline types appears to be implicit in module handlers, which might matter later if the UI ever needs to automatically derive deadlines from module schedules.

Before sketching anything more concrete, I wanted to ask a few questions for the team:

1. Should the new UI eventually replace the existing /manage/{prog}/modules/ page, or live alongside it?
2. Should enabling/disabling modules remain independent from Permission records, or should the system eventually generate those automatically from module schedules?
3. For modules that should always be active (like phase_zero), would it make sense for them to declare an invariant (e.g., something like always_active = True) so the UI can treat them as locked rows?

Happy to share a fuller design sketch if it would help ground the discussion. My main goal here is to make sure the data model direction makes sense before experimenting with any prototypes.