Merge pull request #1449 from pharmaverse/pre-release

Pre release 0.8.1

.github/workflows/common.yml

@@ -2,7 +2,7 @@
 # Source: https://github.com/pharmaverse/admiralci
 # Common workflows designed for Admiral
 # but can be easily used by any other R package
-name: Admiral Workflows
+name: admiral CI/CD Workflows
 
 on:
   # 'workflow_dispatch' gives you the ability
@@ -14,13 +14,15 @@ on:
     branches:
       - main
       - devel
+      - patch
       - pre-release
   # 'pull_request' events are triggered when PRs are
   # created against one of these target branches.
   pull_request:
     branches:
       - main
       - devel
+      - patch
       - pre-release
   # 'release' events are triggered when...
   # you guessed it - when releases are made.

DESCRIPTION

@@ -1,7 +1,7 @@
 Package: admiral
 Type: Package
 Title: ADaM in R Asset Library
-Version: 0.8.0
+Version: 0.8.1
 Authors@R: c(
     person("Thomas", "Neitmann", email = "[email protected]", role = c("aut", "cre")),
     person("Stefan", "Bundfuss", role = "aut"),
@@ -49,7 +49,7 @@ Authors@R: c(
     person("F. Hoffmann-La Roche AG", role = c("cph", "fnd")),
     person("GlaxoSmithKline LLC", role = c("cph", "fnd"))
     )
-Description: A toolbox for programming Clinical Data Standards Interchange Consortium
+Description: A toolbox for programming Clinical Data Interchange Standards Consortium
     (CDISC) compliant Analysis Data Model (ADaM) datasets in R. ADaM datasets are a
     mandatory part of any New Drug or Biologics License Application submitted to the
     United States Food and Drug Administration (FDA). Analysis derivations are

NEWS.md

@@ -1,3 +1,8 @@
+# admiral 0.8.1
+
+- `derive_var_extreme_dt()` and `derive_var_extreme_dtm()` were updated such
+that source observations where the date is `NA` are excluded (#1419)
+
 # admiral 0.8.0
 
 ## New Features

R/derive_var_extreme_date.R

@@ -30,8 +30,9 @@
 #' @details The following steps are performed to create the output dataset:
 #'
 #'   1. For each source dataset the observations as specified by the `filter`
-#'   element are selected. Then for each patient the first or last observation
-#'   (with respect to `date` and `mode`) is selected.
+#'   element are selected and observations where `date` is `NA` are removed.
+#'   Then for each patient the first or last observation (with respect to `date`
+#'   and `mode`) is selected.
 #'
 #'   1. The new variable is set to the variable specified by the `date` element.
 #'   If this is a date variable (rather than datetime), then the time is imputed
@@ -223,6 +224,7 @@ derive_var_extreme_dtm <- function(dataset,
     )
     add_data[[i]] <- source_dataset %>%
       filter_if(sources[[i]]$filter) %>%
+      filter(!is.na(!!date)) %>%
       filter_extreme(
         order = vars(!!date),
         by_vars = subject_keys,
@@ -240,7 +242,6 @@ derive_var_extreme_dtm <- function(dataset,
 
   all_data <- add_data %>%
     bind_rows() %>%
-    filter(!is.na(!!new_var)) %>%
     filter_extreme(
       by_vars = subject_keys,
       order = vars(!!new_var),
@@ -265,8 +266,9 @@ derive_var_extreme_dtm <- function(dataset,
 #' @details The following steps are performed to create the output dataset:
 #'
 #'   1. For each source dataset the observations as specified by the `filter`
-#'   element are selected. Then for each patient the first or last observation
-#'   (with respect to `date` and `mode`) is selected.
+#'   element are selected and observations where `date` is `NA` are removed.
+#'   Then for each patient the first or last observation (with respect to `date`
+#'   and `mode`) is selected.
 #'
 #'   1. The new variable is set to the variable specified by the `date` element.
 #'

README.md

@@ -1,13 +1,11 @@
 # admiral <img src="man/figures/logo.png" align="right" width="200" style="margin-left:50px;"/>
 
 <!-- badges: start -->
+
 [<img src="http://pharmaverse.org/shields/admiral.svg">](https://pharmaverse.org)
 [![CRAN status](https://www.r-pkg.org/badges/version/admiral)](https://CRAN.R-project.org/package=admiral)
-[![R-CMD-check](https://github.com/pharmaverse/admiral/actions/workflows/R-CMD-check.yml/badge.svg)](https://github.com/pharmaverse/admiral/actions/workflows/R-CMD-check.yml)
-[![Style](https://github.com/pharmaverse/admiral/actions/workflows/style.yml/badge.svg)](https://github.com/pharmaverse/admiral/actions/workflows/style.yml)
-[![Spelling](https://github.com/pharmaverse/admiral/actions/workflows/spellcheck.yml/badge.svg)](https://github.com/pharmaverse/admiral/actions/workflows/spellcheck.yml)
-[![Man Pages 📃](https://github.com/pharmaverse/admiral/actions/workflows/man-pages.yml/badge.svg)](https://github.com/pharmaverse/admiral/actions/workflows/man-pages.yml)
-[![Test Coverage](https://raw.githubusercontent.com/pharmaverse/admiral/badges/devel/test-coverage.svg)](https://github.com/pharmaverse/admiral/actions/workflows/code-coverage.yml)
+[![Test Coverage](https://raw.githubusercontent.com/pharmaverse/admiral/badges/main/test-coverage.svg)](https://github.com/pharmaverse/admiral/actions/workflows/code-coverage.yml)
+
 <!-- badges: end -->
 
 ADaM in R Asset Library
@@ -34,22 +32,22 @@ remotes::install_github("pharmaverse/admiral", ref = "devel")
 
 ## Release Schedule
 
-`{admiral}` releases are targeted for the first Monday of the last month of each quarter.  Pull Requests will be frozen the week before a release. 
+`{admiral}` releases are targeted for the first Monday of the last month of each quarter.  Pull Requests will be frozen the week before a release.
 The `admiral` family has several downstream and upstream dependencies and so this release shall be done in three
-Phases:  
+Phases:
 
 * Phase 1 release is for `{admiraldev}` and `{admiral.test}`, which feed into all `admiral` packages
 * Phase 2 release is only for core `{admiral}`
 * Phase 3 release is extension packages, e.g. `{admiralonco}`
 
-| Release Schedule           | Phase 1- Date and Packages   |  Phase 2- Date and Packages | Phase 3- Date and Packages   |
-|----------------------------|------------------------------|---------------------------- |------------------------------|
-| Q4-2022                    |    November 28th             |   December 5th              |  December 12th              |  
-|                            |   `{admiraldev}`             |  `{admiral}`                | `{admiralonco}`              |
-|                            |   `{admiral.test}`           |                             |           |
-| Q1-2023                    |    February 27th             |   March 6th                 |  March 12th               |  
-|                            |   `{admiraldev}`             |  `{admiral}`                | `{admiralonco}`              |
-|                            |   `{admiral.test}`           |                             |              |
+| Release Schedule | Phase 1- Date and Packages | Phase 2- Date and Packages | Phase 3- Date and Packages |
+| ---------------- | -------------------------- | -------------------------- | -------------------------- |
+| Q4-2022          | November 28th              | December 5th               | December 12th              |
+|                  | `{admiraldev}`             | `{admiral}`                | `{admiralonco}`            |
+|                  | `{admiral.test}`           |                            |                            |
+| Q1-2023          | February 27th              | March 6th                  | March 12th                 |
+|                  | `{admiraldev}`             | `{admiral}`                | `{admiralonco}`            |
+|                  | `{admiral.test}`           |                            |                            |
 
 ## Main Goal
 
@@ -72,30 +70,30 @@ achievable---ADaM is endless.
 We will provide:
 
 * A toolbox of re-usable functions and utilities to create ADaM datasets using R scripts in a
-modular manner (an "opinionated" design strategy)
+  modular manner (an "opinionated" design strategy)
 * Pharmaceutical communities and companies are encouraged to contribute to `{admiral}` following
-the provided programming strategy and modular approach
+  the provided programming strategy and modular approach
 * Functions that are comprehensively documented and tested, including example calls---these are
-all listed in the [Reference section](https://pharmaverse.github.io/admiral/reference/index.html)
+  all listed in the [Reference section](https://pharmaverse.github.io/admiral/reference/index.html)
 * Vignettes on how to create ADSL, BDS and OCCDS datasets, including example scripts
 * Vignettes for ADaM dataset specific functionality (i.e. dictionary coding, date imputation,
-SMQs ...)
+  SMQs ...)
 
 ## Types of Packages
 
 There will be 3 foreseeable types of `{admiral}` packages:
 
 * Core package---one package containing all core functions required to create ADaMs,
-usable by any company (i.e. general derivations, utility functions and checks for ADSL, OCCDS and BDS)
+  usable by any company (i.e. general derivations, utility functions and checks for ADSL, OCCDS and BDS)
 * TA (Therapeutic Area) package extensions---one package per TA with functions that are
-specific to algorithms and requirements for that particular TA (e.g. `{admiralonco}`)
+  specific to algorithms and requirements for that particular TA (e.g. [`{admiralonco}`](https://pharmaverse.github.io/admiralonco/index.html))
 * Company package extensions---specific needs and plug-ins for the company, such as access to metadata
-(e.g. `{admiralroche}` or `{admiralgsk}`)
+  (e.g. `{admiralroche}` or `{admiralgsk}`)
 
 ## Admiral Manifesto
 
-For `{admiral}` and all extension packages, we prioritize providing our users with a **simple to adopt** toolkit
-that enables them to produce **readable** and **easily constructible** ADaM programs. The following explains
+For `{admiral}` and all extension packages, we prioritize providing our users with a __simple to adopt__ toolkit
+that enables them to produce __readable__ and __easily constructible__ ADaM programs. The following explains
 our philosophy, which we try to adhere to across the `{admiral}` family of packages.
 There isn’t always a clear single, straightforward rule, but there are guiding principles we adhere to for `{admiral}`.
 This manifesto helps show the considerations of our developers when making decisions.
@@ -104,43 +102,46 @@ We have four design principles to achieve the main goal:
 
 ### Usability
 
-All `{admiral}` functions should be easy to use. 
+All `{admiral}` functions should be easy to use.
 
 * Documentation is an absolute priority. Each function reference page should cover the purpose,
-descriptions of each argument with permitted values, the expected input and output, with clear real-life
-examples---so that users don’t need to dig through code to find answers.
+  descriptions of each argument with permitted values, the expected input and output, with clear real-life
+  examples---so that users don’t need to dig through code to find answers.
 * Vignettes that complement the functional documentation to help users see how best the functions can be
-applied to achieve ADaM requirements.
+  applied to achieve ADaM requirements.
 * Functions should be written and structured in a way that users are able to read, re-use or extend them
-for study specific purposes if needed (see Readability below).
+  for study specific purposes if needed (see Readability below).
 
 ### Simplicity
 
 All `{admiral}` functions have a clear purpose.
 
 * We try not to ever design single functions that could achieve numerous very different derivations. For
-example if you as a user pick up a function with >10 different arguments then chances are it is going to be
-difficult to understand if this function could be applied for your specific need. The intention is that
-arguments/parameters can influence how the output of a function is calculated, but not change the purpose of
-the function.
+  example if you as a user pick up a function with >10 different arguments then chances are it is going to be
+  difficult to understand if this function could be applied for your specific need. The intention is that
+  arguments/parameters can influence how the output of a function is calculated, but not change the purpose of
+  the function.
+
 * We try to combine similar tasks and algorithms into one function where applicable to reduce the amount of repetitive functions with similar algorithms and to group together similar functionality to increase usability (e.g. one study day calculation rather than a function per variable).
 
 * We strive to design functions that are not too general and trying to fulfil multiple, complex purposes.
+
 * Functions should not allow expressions as arguments that are used as code snippets in function calls.
+
 * We recommend to avoid copy and paste of complex computational algorithms or repetitive code like checks
-and advise to wrap them into a function. However we would also like to avoid multi-layered functional nesting,
-so this needs to be considered carefully to keep the nesting of 3-4 functions an exception rather than the rule.
+  and advise to wrap them into a function. However we would also like to avoid multi-layered functional nesting,
+  so this needs to be considered carefully to keep the nesting of 3-4 functions an exception rather than the rule.
 
 ### Findability
 
 All `{admiral}` functions are easily findable.
 
 * In a growing code base, across a family of packages, we make every effort to make our functions easily findable.
 * We use consistent naming conventions across all our functions, and provide vignettes and ADaM templates that
-help users to get started and build familiarity. Each `{admiral}` family package website is searchable.
+  help users to get started and build familiarity. Each `{admiral}` family package website is searchable.
 * We avoid repetitive functions that will do similar tasks (as explained above with study day example).
 * Each package extension is kept focused on the specific scope, e.g. features that are relevant across multiple
-extension packages will be moved to the core `{admiral}` package.
+  extension packages will be moved to the core `{admiral}` package.
 
 ### Readability
 
@@ -149,12 +150,12 @@ that all our developers and contributors must follow, so that all our code has a
 
 * We mandate use of tidyverse (e.g. dplyr) over similar functionality existing in base R.
 * For sections of code that perform the actual derivations (e.g. besides assertions or basic utilities),
-we try to limit nesting of too many dependencies or functions.
+  we try to limit nesting of too many dependencies or functions.
 * Modularity is a focus---we don’t try to achieve too many steps in one.
 * All code has to be well commented.
 * We recognize that a user or a Health Authority reviewer may have the wish to delve into the code base (especially
-given this open source setting), or users may need to extend/adapt the code for their study specific needs. We
-therefore want any module to be understandable to all, not only the `{admiral}` developers.
+  given this open source setting), or users may need to extend/adapt the code for their study specific needs. We
+  therefore want any module to be understandable to all, not only the `{admiral}` developers.
 
 ## References and Documentation
 
@@ -169,11 +170,11 @@ therefore want any module to be understandable to all, not only the `{admiral}`
 
 * [R/Pharma 2021 talk](https://www.youtube.com/watch?v=N7Bw8c3D5fU) (recording)
 * [PHUSE US Connect 2022 pharmaverse workshop](https://github.com/pharmaverse/pharmaverse.workshop.phuseUS2022) (slides and materials---including `{admiral}`
-workshop slides from PHUSE EU Connect 2021)
+  workshop slides from PHUSE EU Connect 2021)
 
 ## Contact
 
 We use the following for support and communications between user and developer community:
 
-* [Slack](https://app.slack.com/client/T028PB489D3/C02M8KN8269)---for informal discussions, Q&A and building our user community. If you don't have access, use this [link](https://join.slack.com/t/pharmaverse/shared_invite/zt-yv5atkr4-Np2ytJ6W_QKz_4Olo7Jo9A) to join the pharmaverse Slack workspace
+* [Slack](https://app.slack.com/client/T028PB489D3/C02M8KN8269)---for informal discussions, Q\&A and building our user community. If you don't have access, use this [link](https://join.slack.com/t/pharmaverse/shared_invite/zt-yv5atkr4-Np2ytJ6W_QKz_4Olo7Jo9A) to join the pharmaverse Slack workspace
 * [GitHub Issues](https://github.com/pharmaverse/admiral/issues)---for direct feedback, enhancement requests or raising bugs

docs/pkgdown.yml

@@ -13,7 +13,7 @@ articles:
   lab_grading: lab_grading.html
   occds: occds.html
   queries_dataset: queries_dataset.html
-last_built: 2022-08-26T19:51Z
+last_built: 2022-09-09T10:59Z
 urls:
   reference: https://pharmaverse.github.io/admiral/reference
   article: https://pharmaverse.github.io/admiral/articles