Handle messaging around model treatment of missingness

[jamesmbaazam]

Description

This PR closes #771 by adding a message to inform users about how NA's are treated in the default model. It also points to alternatives given the user's use case. This PR also adds missing tests for obs_opts().

Initial submission checklist

• My PR is based on a package issue and I have explicitly linked it.
• I have tested my changes locally (using devtools::test() and devtools::check()).
• I have added or updated unit tests where necessary.
• I have updated the documentation if required and rebuilt docs if yes (using devtools::document()).
• I have followed the established coding standards (and checked using lintr::lint_package()).
• I have added a news item linked to this PR.

After the initial Pull Request

• I have reviewed Checks for this PR and addressed any issues as far as I am able.

[sbfnk]

Nice - some suggestions for (I think) slightly clearer wording. I think we should be more restrictive about when this message is shown (e.g. it should be suppressed when there is no missing data).

[sbfnk]

Thanks, this looks good.

It's adding a fair amount of infrastructure (an additional function + return value in obs_opts() that needs to be removed) just to be able to show that message. Shall we give it an expiry (and use keyword "deprecated" somewhere)?

[jamesmbaazam]

Thanks, this looks good.

It's adding a fair amount of infrastructure (an additional function + return value in obs_opts() that needs to be removed) just to be able to show that message. Shall we give it an expiry (and use keyword "deprecated" somewhere)?

Was this what you meant? https://github.com/epiforecasts/EpiNow2/pull/774/files#diff-6cd987920443d42098a4963d43b2e0efec9fd16f9198d66705e6d95094e3b87aR185-R194.

[sbfnk]

Thanks, this looks good.
It's adding a fair amount of infrastructure (an additional function + return value in obs_opts() that needs to be removed) just to be able to show that message. Shall we give it an expiry (and use keyword "deprecated" somewhere)?

Was this what you meant? https://github.com/epiforecasts/EpiNow2/pull/774/files#diff-6cd987920443d42098a4963d43b2e0efec9fd16f9198d66705e6d95094e3b87aR185-R194.

Yes, I think this will do.

[jamesmbaazam]

Converting this PR to a draft to start a discussion before opening for review.

I'm a little torn and need your opinion (@sbfnk & @seabbs). I have two options here:

1. Allow check_na_setting_against_data() to call test_data_complete() so that the check is self-contained; small issue is they will share the cols_to_check argument. I think that argument doesn't make sense in the signature of check_na_setting_against_data(). This couples the two functions and there isn't complete separation of concerns.
2. Only call check_na_setting_against_data() if test_data_complete() returns false

Here, the change required in estimate_infections() and estiamte_secondary() will be:

if (!test_data_complete(data, cols_to_check)) {
		check_na_setting_against_data(data, obs)
}

This second option would mean that check_na_setting_against_data(data, obs) would not check if the data is complete and would unconditionally throw the message about treatment of NA's.

Which one makes sense to you? Is there an option I'm missing?

UPDATE:

• I decided to go with option 1.

[sbfnk]

Looks good to me - just needs the reviewer / PR number added.

[sbfnk]

I think the check failures might be related to epinowcast/actions#24 - I'll clear the cache and run again.

[jamesmbaazam]

I think the check failures might be related to epinowcast/actions#24 - I'll clear the cache and run again.

It was related to future being required to to run test-setup-future. I now install it in the CI in #827. Will rebase this on main when #827 is merged.

[sbfnk]

I think the check failures might be related to epinowcast/actions#24 - I'll clear the cache and run again.

It was related to future being required to to run test-setup-future. I now install it in the CI in #827. Will rebase this on main when #827 is merged.

That was an additional issue - this one was related to the cache (and was successful after clearing it): https://github.com/epiforecasts/EpiNow2/actions/runs/11290308841

Agreed.