add project-level metadata to export options

[timothytsai]

Hi,

It would be useful to be able to export project-level metadata, specifically project ID. Our use case is creating links to records in conjunction with the REDCap version number (already exportable).

I have a working implementation at my fork (timothytsai@9a7bf00), which I can convert to a pull request if desired.

Cheers,
Tim

[wibeasley]

I've thought about this a few times, and I think it should be a distinct function. I've seen some good arguments why the output structure of a function shouldn't depend on the parameter values (example). In project/metadata were combined in the same function, the returned dataset would have different columns, depending project or metadata is passed to 'content'.

@timothytsai, Would you like to write a new function for it? You've done most of the work already, and seem to have a good feel for the internals of REDCapR functions. I'm happy to add you as a contributor.

I played around with this function for sake of a documentation example. Since the dataset is guaranteed to have only one row, I wondered if the return should be a conventional list: https://github.com/OuhscBbmc/REDCapR/blob/dev/R/kernel-api.R

Also, do you see a benefit of casting the values to an appropriate data type? For example, project_id could be returned as an integer, instead of a string. If it helps anyone visualize this, here's what the output when everything is left as a string. The readr::spec attribute should probably be stripped out.

$project_id
[1] "153"

$project_title
[1] "REDCapR Target Simple Static -see https://github.com/OuhscBbmc/REDCapR"

$creation_time
[1] "2013-11-29 15:58:20"

$production_time
[1] NA

$in_production
[1] "0"

$project_language
[1] "English"

$purpose
[1] "0"

$purpose_other
[1] NA

$project_notes
[1] NA

$custom_record_label
[1] NA

$secondary_unique_field
[1] NA

$is_longitudinal
[1] "0"

$surveys_enabled
[1] "0"

$scheduling_enabled
[1] "0"

$record_autonumbering_enabled
[1] "1"

$randomization_enabled
[1] "0"

$ddp_enabled
[1] "0"

$project_irb_number
[1] NA

$project_grant_number
[1] NA

$project_pi_firstname
[1] NA

$project_pi_lastname
[1] NA

$display_today_now_button
[1] "1"

$has_repeating_instruments_or_events
[1] "0"

attr(,"spec")
cols(
  .default = col_character(),
  project_id = col_character(),
  project_title = col_character(),
  creation_time = col_character(),
  production_time = col_character(),
  in_production = col_character(),
  project_language = col_character(),
  purpose = col_character(),
  purpose_other = col_character(),
  project_notes = col_character(),
  custom_record_label = col_character(),
  secondary_unique_field = col_character(),
  is_longitudinal = col_character(),
  surveys_enabled = col_character(),
  scheduling_enabled = col_character(),
  record_autonumbering_enabled = col_character(),
  randomization_enabled = col_character(),
  ddp_enabled = col_character(),
  project_irb_number = col_character(),
  project_grant_number = col_character(),
  project_pi_firstname = col_character(),
  project_pi_lastname = col_character(),
  display_today_now_button = col_character(),
  has_repeating_instruments_or_events = col_character()
)

[timothytsai]

Hi @wibeasley , I'd love to give it a shot. I will plan to add this as a new function, returning a list with appropriate data types. I'll do some research into matching the data types to the types in the backend.

I'll try to emulate the existing formatting of your code as best I can, but do please let me know if there are any specific coding style conventions that I should take note of.

[pbchase]

I started writing this yesterday as a hack of redcap_metadata_read before I found this issue. The working title of the draft function is redcap_project_info_read. Our use-case is to verify a token belongs to a project by loading the token and a PID via the same .env file, connecting, reading the project PID from the server, and testing for a match.

What's the status on your work, @timothytsai?

[timothytsai]

Hi @pbchase , I am hoping to pick this up again this month. My fork at timothytsai@9a7bf00 is the modification of the existing function, which should be migrated to its own function as it sounds like you have started.

[wibeasley]

@timothytsai, sorry the timing didn't work at REDCapCon to catch up. I was hoping to chat.

Unrelated, I was reviewing the older issues in this repo and realized that @skadauke's suggestion in #410. I wished I figured it out sooner, so I wouldn't have duplicated some of your work from 2018. Start a new issue and reference this one if youthink there's something missing (from the function that was added last month).

• https://ouhscbbmc.github.io/REDCapR/reference/redcap_project_info_read.html
• https://github.com/OuhscBbmc/REDCapR/blob/HEAD/R/redcap-project-info-read.R

[timothytsai]

Hi @wibeasley, good to see you at REDCapCon! I will check out #410 and see. REDCap (and REDCapR) have certainly grown in the last couple of years.