Refactoring getParticipants API

[anthonypetersen]

With the current state there is a lot of confusion when talking about the getParticipants API. The confusion always seems to stem from the fact that filter is one of the types you can pass in. If you pass in that type you also need to pass in an option. What I also noticed is that if filter is passed in as the option we are using a completely different function to return data. My idea is to split the filter option into its own API called filterParticipants. We would keep getParticipants as an API but we would use it as an API where people can return data based on pre-determined queries such as verified and consentNotSubmitted and filterParticipants would be an API where users would need to pass in both a field they want to filter by as well as the value that the filter should match.

Thoughts on this?

[anthonypetersen]

If we decided to pursue this type of solution we would also want to consider where types such as individual and refusalswithdrawals fall.

For reference, the entry point of the code I'm mostly referring to is below:

[JoeArmani]

Please keep in mind I'm not familiar with the use cases here...

It's probably more straightforward for the end users when separate APIs with required args are defined and documented rather than one API with optional args, so separating this into separate APIs makes a lot of sense.

Beyond that, maybe we don't need to change the getParticipants implementation? Can we just validate based on the API called and then pass that data into getParticipants()?

[anthonypetersen]

We could easily do something like that where it still filters into one. It was just more the fact that some options lead toward retrieveParticipants() and some options lead toward filterDB() or individualParticipant() that makes me think they should be different APIs since the base functionality is totally different.

[JoeArmani]

Ahh got it. Thanks for the explanation.

I see it's handling many different cases in the decision structure, but because of the else-ifs, it probably isn't doing too much unnecessary data processing.

I guess I don't have a strong opinion either way - whatever you think is the best combination of user-friendliness and maintenance.

[anthonypetersen]

No problem. Yeah I guess that's the bigger part, the functionality works but folks who use it or need to describe it that aren't as technical get confused quite easily.

[we-ai]

I agree the API handles mixed situations and is confusing.
The API can be split into into 3, based on each situation handled:

• getParticipants: the type can be "verified", "notYetVerified", "cannotBeVerified", "profileNotSubmitted", "consentNotSubmitted", "notSignedIn", "all" (fallback value ?), "active", "notActive", "passive", or "individual"(or put "individual" in a getIndividualParticipant API?).
• getFilteredParticipants
• getRefusalWithdrawalParticipants

[anthonypetersen]

I feel like individual could almost be entirely removed since we have an option to filter by token inside of filter