Use case:
Dozens of users in a data commons are using Atlas to create concept sets and cohort definitions. Many of them are just learning how build these artifacts and some have obtained mastery. Users do want to view/browse concept sets and cohort definitions that could be useful for their analyses (reusability) but often other users would prefer that their artifacts not be listed until they give permission (e.g., because they are in draft mode or private to a project or team).

Current behavior:
All users will see up to hundreds of concept sets and cohort definitions when they click on the #/conceptsets and #/cohortdefinitions endpoints in Atlas. This can be very confusing to the users as they will see numerous things that are described only by title and often with little context to help them know if its relevant to their project. They might not have a way of knowing know if the artifacts are in draft mode or have been tested. Also, many users would prefer the ability to give permission to share the viewing/listing of their artifacts with either specific individuals, groups, or the community of users as a whole. Reasons for wanting to control access include a desire to wait until the artifact is solidly tested prior to contributing it to the community, wanting the the project to be complete and published before they share the work, or other reasons.

Proposal:
Modify the WebAPI to use a new property setting that will cause the WebAPI instance to return only concept sets, cohort definitions, or other artifacts (e.g., incidence rate analysis, characterizations, etc) in the response provided by endpoints such as #/conceptsets, #/cohortdefinitions, etc. that a user has explicit permission to view based on the sec_role_permission and sec_permission tables in the security schema.

Justification for doing this in WebAPI:
It seems more appropriate from an authorization standpoint for the service to filter artifact lists based on the authenticated user's permissions rather than having the client application (Atlas) do so. In the latter case, the client app still receives a listing that someone could sniff using developer tools within the browser. Note that if this idea is accepted, it will likely make sense to add the ability of an author to edit read permissions using Atlas "Configure access". This will add a new ability given that the current Configure Access focuses only on whom can edit an artifact.

Additional considerations:

• If a user creates X number of concept sets (or cohort definitions etc.), will they have to go into all X and specify the invited permissions?
• Is there a way to create user groups so that a user can invite a group of users (perhaps through group roles)?
• (Add more in comments so that we can design this well)