Allow data_access_group field in user import to preserve DAG

[jubilee2]

If data_access_group is excluded from user import, REDCap interprets
the absence as the user having no DAG, causing DAG assignments to be
lost on every import. Including this field preserves existing DAG
assignments when updating user records via the API.

[spgarbet]

✖ | 1       34 | 357-prepUserImportData                                 
────────────────────────────────────────────────────────────────────────
Failure (test-357-prepUserImportData.R:15:7): Use consolidate = TRUE
all(ImportUser[[v]] %in% c(0, 1)) is not TRUE

`actual`:   FALSE
`expected`: TRUE 

This is the code we just did a lot of work on around userImports. The exclusion of DAG on this was what made it work before. We need to dive in a little deeper. @couthcommander you did some work on this. Thoughts?

[couthcommander]

It's complicated, and I'm not sure if this is a new complication or an old complication. But I can confirm that production code resets DAG to "not assigned to group".

exportUsers returns three columns of interest: data_access_group, data_access_group_id, data_access_group_label
As an example, these might be "test_dag_1" / 181227 / "Test DAG 1". The user provides the label ("Test DAG 1") while REDCap creates the other two. Well, exportUsers always gives NA for "data_access_group".

importUsers currently ignores "data_access_group" and "data_access_group_id". In theory, setting "data_access_group_label" would set the DAG properly. It doesn't. Maybe it did a month ago, maybe it never did. From the API playground, you must set the DAG with "data_access_group" (this PR allows you to do that). exportUsers needs to be fixed for full functionality.

And then...

"data_access_group" is part of "REDCAP_USER_TABLE_ACCESS_VARIABLES" (see redcapDataStructure). This is intended to be used to define 0/1 permissions (ie, does this user have access to the DAG form?). I'm not sure if this is correct. exportUsers exports a fourth column of interest, "data_access_groups". It's possible this is the variable intended to be the 0/1 permission. This makes sense if "data_access_group" is the method used to get/set the actual DAG. So I think that's not defined correctly.

Furthermore...

There are API functions for user DAG assignment. There's also the REDCAP_SYSTEM_FIELD "redcap_data_access_group", but I think it's not relevant.

Ultimately, I recommend we collectively meet and test behaviour on the API playground to determine how redcapAPI should work.

[spgarbet]

Thanks. I think we should take the position of the following: I'm an API user and I need to import / export User information. How should this work? Underneath we can call multiple APIs and deal with the complexities, but it seems possible the current function interface doesn't meet the use cases properly. I.e., we consider what we want to do, design that call and then create functions that do tat.

[couthcommander]

Several improvements are needed, see #500

[jubilee2]

This update is already included in #501. I will close this one.