Closed ajelhajj closed 8 months ago
My take on this is that it is an upstream error not being handled by the REDCap server properly. However, it is possible in this library to add errors for such cases and stop processing. The current code makes sure there's no conflicts so the library is helping the user in that regard. I checked the help documents the REDCap server team provides and the username requirements are not listed.
Thinking further about it, this library cannot download a list of possible users to check if they exist. I think this may be something to request from the core REDCap server team.
It seems that e-mail addresses are valid for use as user names. It's theoretically possible to check a name for validity on those terms. I've tried this before, although we didn't include it as a validation in exportRecordsTyped.
That's about as far as we could get though. @spgarbet is correct that we have no feedback from the server on whether a username exists in the system.
@nutterb should we just close this or should I forward it to the core REDCap team?
I'm inclined to close it and send it on to REDCap. The best we'd ever be able to do for this is capture an error of a non-existent user coming back from REDCap. But I can see the argument for not returning such an error, as it could be used to fish for user names on the system. I'm not an expert in cyber security, though, so not sure what the best practice is there.
Either way, it's their decision to make.
An error is returned when the username is invalid in the sense that it contains something other than letters, numbers, underscores, hyphens, periods, spaces, apostrophes, or @ symbols, there is no error when a non-existent user is fed to the function.
In my case, a user of theREDCap will be responsible for tying the usernames of CRCs they'd like to be added into a REDCap textbox variable which my ETL eventually attempts to import into the project.