Developer and test support

Developers and testers need to work with system accounts, both for administration and to mimic participants. Right now we facilitate this work by giving developers and testers the “researcher” and “study coordinator” roles, which gives them access to production study participant accounts, which is not appropriate. To allow developers and testers to work with Bridge accounts, without compromising participant anonymity, I propose the changes described below:

First, the “test_user” flag should be made immutable (unremovable). There’s no real-world case I can think of where someone wanted to convert a test account to a production account. You would just delete the test account and start over.

All APIs in the ParticipantController and StudyParticipantController (a few dozen endpoints) will be changed so that if the caller is a developer, the target account must be tagged with the test_user data group or an error will be returned. This includes creating, retrieving, and updating accounts, triggering behavior on behalf of an account, etc. For the search APIs, the “requires test_user” condition will be mandatory on any search conducted by a developer.

If an account has the RESEARCHER/STUDY_COORDINATOR roles as well as DEVELOPER and/or STUDY_DESIGNER, they are given the scope of these wider permissions, and are not treated like developers.

The study designer role is a subset of a developer role that can only access study-specific participant APIs. All the same changes will be made for this role, but only for the APIs it can access.

I don’t know what this will look like in the Bridge Study Manager. I may just make a lot more pages accessible to developers, but they’ll only be shown the test accounts in the app/study.