ropensci / ruODK

ruODK: An R Client for the ODK Central API
https://docs.ropensci.org/ruODK/
GNU General Public License v3.0
42 stars 13 forks source link

form_schema() returns incorrect types #101

Closed mtyszler closed 3 years ago

mtyszler commented 3 years ago

Problem

When using form_schema() the return types are incorrect. In particular, select_one, for example, is returned as string.

I believe this is a problem of the API, as reported in https://forum.getodk.org/t/incorrect-type-returned-by-api-form-schema-fields/31044, but I thought it would be good to flag here.

Reproducible example

library(ruODK)

ru_setup(
    un = "...",
    pw ="...", 
    url = "https://odkc.dbca.wa.gov.au",
    pid = 2,
    fid = "I8n_no_lang")

frm <-form_schema()

frm[6,]
# expect type to be select1, shows string
Session Info ```{r} # utils::sessionInfo() R version 3.6.3 (2020-02-29) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 17763) Matrix products: default locale: [1] LC_COLLATE=Dutch_Netherlands.1252 LC_CTYPE=Dutch_Netherlands.1252 LC_MONETARY=Dutch_Netherlands.1252 [4] LC_NUMERIC=C LC_TIME=Dutch_Netherlands.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] ruODK_0.9.2.9001 loaded via a namespace (and not attached): [1] Rcpp_1.0.5 rstudioapi_0.11 xml2_1.3.2 janitor_2.0.1 magrittr_1.5 tidyselect_1.1.0 R6_2.5.0 [8] rlang_0.4.8 fansi_0.4.1 stringr_1.4.0 httr_1.4.2 dplyr_1.0.2 tools_3.6.3 utf8_1.1.4 [15] cli_2.1.0 ellipsis_0.3.1 assertthat_0.2.1 tibble_3.0.4 lifecycle_0.2.0 crayon_1.3.4 purrr_0.3.4 [22] tidyr_1.1.2 vctrs_0.3.4 curl_4.3 glue_1.4.2 snakecase_0.11.0 stringi_1.5.3 compiler_3.6.3 [29] pillar_1.4.6 generics_0.1.0 jsonlite_1.7.1 lubridate_1.7.9 pkgconfig_2.0.3 ```
mtyszler commented 3 years ago

See discussion at https://github.com/getodk/central-backend/issues/306 and https://forum.getodk.org/t/incorrect-type-returned-by-api-form-schema-fields/31044

florianm commented 3 years ago

Thanks for the report and the follow-up.

The underlying data types indeed are different from the widget types, so from a pure data analysis perspective it makes sense to get "string" for a choice field. The information not provided by form_schema, such as widget type or skip logic, is part of the form definition, which is available as form_xml.

What could be a good use case for a user to get widget type programmatically via ruODK beyond existing functionality: