-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closes #2185 additional implementation of keep_source_vars
#2215
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the vignettes need to be updated that use this function
@@ -422,7 +431,7 @@ derive_param_tte <- function(dataset = NULL, | |||
} | |||
|
|||
adsl <- dataset_adsl %>% | |||
select(!!!adsl_vars) | |||
select(!!!adsl_vars, !!!keep_source_vars) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using keep_source_vars
here is different from the other functions. Usually it is used to specify the variables which should be kept from the selected records. To be consistent we would need to add keep_source_vars
to event_source()
and censor_source()
. However, I am not sure if this is a good idea (especially if the default is exprs(everything())
because different source datasets could be used. For example if event_source()
uses ADRS and censor_source()
uses ADSL, all ADRS and all ADSL variables would be added to the new records but the ADSL variables would be populated for censored records only.
Therefore I think we should not add keep_source_vars
to derive_param_tte()
.
@bms63 , what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bms63 @bundfussr I think it's fine if we don't implement it here too, derive_param_tte()
seems hyperspecific for users, in which case we can just close the PR as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine to not implement this change. @zdz2101 when you return - can you make a note of this in the function re-work documents.
Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the
devel
branch until you have checked off each task.styler::style_file()
to style R and Rmd filesdevtools::document()
so all.Rd
files in theman
folder and theNAMESPACE
file in the project root are updated appropriatelyNEWS.md
under the header# admiral (development version)
if the changes pertain to a user-facing function (i.e. it has an@export
tag) or documentation aimed at users (rather than developers)pkgdown::build_site()
and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.lintr::lint_package()
R CMD check
locally and address all errors and warnings -devtools::check()