Closed cjyetman closed 11 months ago
I guess this is the part we would (possibly) rather remove long term? So in theory if we were to create a project code "XXX", the function would indicate we want to add the TDM.
is the reason we are not just setting
valid_project_code <- FALSE
simply that we want the test to still pass
Honestly, I just can't think of a clean way of doing this (effectively disabling TDM everywhere but leaving all the code in place). valid_project_code <- FALSE
does make more sense, but yeah.... then we would have to disable/remove the test because it can't possibly return TRUE
. 🤔
I guess this is the part we would (possibly) rather remove long term? So in theory if we were to create a project code "XXX", the function would indicate we want to add the TDM. is the reason we are not just setting
valid_project_code <- FALSE
simply that we want the test to still passHonestly, I just can't think of a clean way of doing this (effectively disabling TDM everywhere but leaving all the code in place).
valid_project_code <- FALSE
does make more sense, but yeah.... then we would have to disable/remove the test because it can't possibly returnTRUE
. 🤔
valid point about keeping everything in place
TDM should no longer be used in GENERAL reports, so the logic here needs to drop that hard-coded relationship.
related https://github.com/RMI-PACTA/pacta.portfolio.report/pull/39 related https://github.com/RMI-PACTA/templates.transition.monitor/pull/5
Update: had to also modify a test for
tdm_conditions_met()
which assumed that "GENERAL" is a valid project code