Exporting related reports family only labels families with a primary study#544

When I use export to generate a table of studies with the related reports family bibliographic data, it only labels families with a primary report marked. I tested it by marking a primary report in a related report family that the export missed and it showed up in the new export. I think it’s intended to export them all, but if it’s supposed to only show ones with a primary report, that should be more clear. We usually mark a primary study, but sometimes studies overlap and neither is obviously primary, or we’re waiting to see which time points we want to use, etc, and don’t mark one.

Thanks!

Ah, interesting. I tried to replicate, but difficult to tell where no primary was marked. I know that for presentation purposes, we had some functions related to a “Primary”; we also use the Primary as the name/placeholder for the whole family.

I definitely recommend marking a Primary until we can figure out what is not working about RR families without primaries. Sorry for the issues!

Oh, and to try to save you some annoyance… I checked, the Inspector Related Report Families filter is not having these issues, so you can filter to families and then mark Primaries, I hope that prevents too much re-review

Yeah, I grabbed the data from Inspector with no issues, so no problem there! Just wanted to flag a behavior that didn’t match what I expected to happen. Thank you for looking into it!

Highly, highly appreciated– you definitely have the ‘bugfinder’ badge if we have badges!

Interestingly, this is intended behavior, in the sense that our code documents it as an intentional choice

  /**
   * a group is valid when it's used for AutoLit, or it has a primary and is used for Synthesis
   */

Even more interestingly

1. We don’t honor this for building PRISMA (any group is considered, regardless of if a primary is designated).
2. The only place we enforce this rule (primary required) is on Synthesis>Export

So… do we want to change that? If we didn’t document why this choice was made, and we now consider it an encumbrance, we should probably just allow all groups through.

My only hunch is that we used to not have related report group names, and the group primary was used as label. If the group had no primary, it had no label, and therefore was not suitable for Synthesis.

Now, when there’s no primary, we have:

1. The group name specified by users
2. Absent (1), we use comma-separated ref ids of all reports in the group to distinctly label.

Which is likely good enough.

Totally happy with your proposed approach here, I recall that we were considering Synthesis groupings and labels when we made that decision, but grouping (or at least identifying RR Families by the user-supplied name or RefIDs) is more useful in pretty much all cases

Just an additional thought in support of using user-specified names, in the most recent project, we had 3-4 families whose primary report was by the same author and either the same year or close, so we named them by NCT number of the underlying trials instead of author/year of the primary. Rare to have an author publishing that often, but I like having the ability to side step the problem and use a different label! Thanks!