Allow for condititional analyze subtables

[gmbecker]

i.e., make this work:

afun <- function(x, .spl_context) {
    if(tail(.spl_context$value, 1) == "A")
        NULL
    else
        rcell(length(x))
}


lyt <- basic_table() %>%
    split_cols_by("ARM") %>%
    split_rows_by("STRATA1") %>%
    analyze(c("AGE", "SEX"),
            afun = list(AGE = mean, SEX = afun))

Currently it gives

> build_table(lyt, ex_adsl)
             A: Drug X          B: Placebo       C: Combination 
————————————————————————————————————————————————————————————————
A                                                               
  AGE                                                           
    AGE   33.0789473684211   35.1136363636364        34.225     
  SEX                                                           
    SEX                                                         
B                                                               
  AGE                                                           
    AGE   33.8510638297872          36          36.3255813953488
  SEX                                                           
    SEX          47                 45                 43       
C                                                               
  AGE                                                           
    AGE   34.2244897959184   35.1777777777778   35.6326530612245
  SEX                                                           
    SEX          49                 45                 49       

But there should be some way to make it give

> build_table(lyt, ex_adsl)
             A: Drug X          B: Placebo       C: Combination 
————————————————————————————————————————————————————————————————
A                                                               
  AGE                                                           
    AGE   33.0789473684211   35.1136363636364        34.225     
B                                                               
  AGE                                                           
    AGE   33.8510638297872          36          36.3255813953488
  SEX                                                           
    SEX          47                 45                 43       
C                                                               
  AGE                                                           
    AGE   34.2244897959184   35.1777777777778   35.6326530612245
  SEX                                                           
    SEX          49                 45                 49       

ie we want the SEX subtable underneath strata B and C, but NOT under strata A.

Motivated by internal user request.

[gmbecker]

@shajoezhu @pawelru @cicdguy Do we have a canonical way of referencing internal things (e.g., roverflow) in public facing discussions.

If not, we should...

[shajoezhu]

hi @gmbecker , not for roverflow. as these are internal links

[gmbecker]

Yes, i understand, thats why I didn't link it here, but there should be some way of indicating it originates there, or some other way of linking between the systems. Or at the very least a label that indicates its provenance in vague terms somehow

[pawelru]

Codewise - no we don't and we shouldn't. By codewise I mean put references to internal system in e.g. NEWS file or as a commented out lines. Codebase should be completely company independent so that (clearly theoretically) a developer from the outside of our company will have all the information he needs.

Issuewise - this is more flexible but still with some restrictions. Again, we cannot put internal links (including roverflow or gdoc). On the other hand, I think it's fine to state that the problem is coming from business internal needs. Or label issue somehow if that helps you organising work.

Here, I would recommend to ask internal stakeholders to work on good (and compliant!) question / bug / feature request and create ticket here. This ofc means some work on them. But I see a few long-term wins. (i) This would benefit overall community as someone else might have similar problem in the future or even community could help. (ii) This would also teach internal R users how and where to find help in case of non-internally built packages. They need to know about existence of DESCRIPTION file with all relevant references and links that allow to reach out to authors / maintainers. (iii) Speed of feedback. Some will probably disagree with me but I would expect that repo ticket would be addressed quicker that internal system posts or whatever.

By all means - we cannot put real patient data

(regarding above - we can add yet another checkbox / headline in the issue template @cicdguy wdyt?)

-- UPDATE ---

This is already included in the Security Policy. In particular: not to include PHI.

[cicdguy]

Yes please, if you want to cross-reference internal links, use a private forum as we have private chat channels for communicating with internal stakeholders.

[gmbecker]

@pawelru @cicdguy For this to really be feasible and actually I think there needs to be links to the relevant repos in the internal roverflow interface for the users there to follow here. I don't have any insight into what the process of trying to put that in place would look like.

And to be clear, I fully understand that we can't link to internal resources (which is why I didn't when creating this issue) or (obviously) ever have real patient data in a public issue.

My larger point is that this issue was a direct ask (by way of question) from a trial team member, and tracking that fact will be useful/important when prioritizing work. I did this in a completely ad hoc way by creating a "user_request" label and applying it, but that has very limited value if I'm the only one doing it and only on this repo. I'm suggesting some sort of NEST wide standard for flagging that, even if its just "trial_request" and/or "collaborator_request" labels that are consistently used and tracking down the specific asks is "left to the reader"