Changes to this issue were made in two places, primarily in #933 but also in #934. To avoid confusion in the testing phase - I'm providing a summary of everything that happened in this ticket.
It was initially noted that fields relating to the Vaccination Global page were being stored under a model titled ControlMasterPlan. This includes (but is not limited to) fields such as "Vaccination Capacity", "Vaccination Priority Order", and "Restart Vaccination Capacity". Also included in this model was a text field called "name" which was being used to store the control master plan name located on the main controls page. It was the inclusion of this field that initially lead me to the conclusion that this model was being used for two separate purposes.
To migrate the name I refactor the entire front end to change every instance of "ControlMasterPlan" to "VaccinationGlobal". I also refactored the C-Engine to reflect this change. After some C-Engine build issues everything seemed to be working properly.
Unknowingly to me at the time, I opened a new ticket related to this issue (#934). After diving into #934 I discovered that there was still a need for a ControlMasterPlan model. I re-added a ControlMasterPlan table and the appropriate fields.
Despite a large number of commits made in both #934 and #933, the only change made on the front end should be that the Controls tab should no include have validation. New scenarios should come with a green marker on the Controls tab.
The database however, should reflect a number of changes. Here is what the database structure should look like after these changes.
Testing should confirm that front-end changes have remained minimal and that all Controls and Vaccination Global options are still working as expected. Testing should also confirm that the database reflects the above outline.
Changes to this issue were made in two places, primarily in #933 but also in #934. To avoid confusion in the testing phase - I'm providing a summary of everything that happened in this ticket.
It was initially noted that fields relating to the Vaccination Global page were being stored under a model titled ControlMasterPlan. This includes (but is not limited to) fields such as "Vaccination Capacity", "Vaccination Priority Order", and "Restart Vaccination Capacity". Also included in this model was a text field called "name" which was being used to store the control master plan name located on the main controls page. It was the inclusion of this field that initially lead me to the conclusion that this model was being used for two separate purposes.
To migrate the name I refactor the entire front end to change every instance of "ControlMasterPlan" to "VaccinationGlobal". I also refactored the C-Engine to reflect this change. After some C-Engine build issues everything seemed to be working properly.
Unknowingly to me at the time, I opened a new ticket related to this issue (#934). After diving into #934 I discovered that there was still a need for a ControlMasterPlan model. I re-added a ControlMasterPlan table and the appropriate fields.
Despite a large number of commits made in both #934 and #933, the only change made on the front end should be that the Controls tab should no include have validation. New scenarios should come with a green marker on the Controls tab.
The database however, should reflect a number of changes. Here is what the database structure should look like after these changes.
Table: ControlMasterPlan Fields:
Table: VaccinationGlobal Fields:
Testing should confirm that front-end changes have remained minimal and that all Controls and Vaccination Global options are still working as expected. Testing should also confirm that the database reflects the above outline.