Don't store Tuning in BTM #37
Description
In #33 we added a Tuning column/field to BTM, and it behaves just like the other columns in the same table (measured value is provided, then reported value is editable). There is both a visible HTML table and Oracle database table that contain the new column. However, after further review, this column needs to be read-only (the reported value). Otherwise, it's an onerous and unnecessary exercise to make changes to Tuning as the data is then in both BTM and DTM and changes would need to be made in two places, or more likely they'd get out-of-sync. Plus, the "real" value is no longer clear. Instead, the data should live only in DTM, and be read-only in BTM.
We need to undo the Oracle database table changes. Plus the HTML table needs to be modified such that the measured and reported values are both read-only.
Note 1: This has significant ramifications. The coupling between DTM and BTM becomes dangerously tight. And it becomes impossible to simply query the BTM database to determine the state of any given machine timesheet. Further, the value of Tuning in DTM isn't a simple column sitting in a table row keyed by a specific timesheet. Instead, it's obtained via a very complex and costly query to search across multiple tuning records, and navigating interval boundaries. We need to decide how best to make this integration, probably either (A) JSON web service or more likely (B) Oracle cross-schema View.
Note 2: The tuning field is not just informational only - it is part of the mutual exclusive rules. If we're tuning, we're not doing the other internal things like NPES Restore or ACC. Plus, Tuning occurs only during physics so subtracts from physics delivery. A whole new set of cross-checks opens up.
Aside: The DOWN column should probably behave this way as well. This is likely a problem for another day though. It gets tricky with FSD, plus BOOM and DTM may be out-of-sync.