Target release TBD Epic Document status Document owner Meredith Slota (Unlicensed) Designer Ljubomir Bradic (Unlicensed) Developers John Hill QA @TBD

Goals

• Enable anonymous users to access approved data(sets) within Synapse
• "Open Access" within Synapse
• Configuration for Community Portal prototypes
• 1-pager: https://docs.google.com/document/d/1PxXos689nrSQxUH5cnbo1zpiYfNZz8Pt9NAdCxNdy1M/edit

Background and Strategic Fit

Why are you doing this? How does this relate to your overall product strategy?

Assumptions

• List the assumptions you have such as user, technical or other business assumptions. (e.g. users will primarily access this feature from a tablet).

Requirements

User Cases

Background: Alice (Anna Greenwood (Unlicensed)) is a researcher who is responsible for creating the content to power the AMP-AD Community Portal. She wants other users to download data relevant to their work, but before they can do that, she's interested in allowing them to find datasets in Synapse that have been published by the AMP-AD consortium. Bob is an external user who does not yet have a Synapse account, but he heard of the AMP-AD Community Portal at a recent conference and is interested in exploring their data to see if there's anything relevant to his own work. 

Use Case 1: Anonymous Access to Data Stored in a Table (Sage Process)

Alice has organized key metadata into a Table, and wants the Community Portal frontend components to query this table specifically to allow Bob a useful query interaction. The frontend component uses the facet functionality from Tables to allow for a useful UI to explore relevant data. Alice expects to request and receive approval from her manager at Sage to make this Table public (e.g. downloadable by anonymous users). 

Workflow

1. Alice builds her Table: defines the schema and loads the appropriate data.
2. Alice works with her senior leadership at Sage to get written approval to release this data publicly. (Process TBD.) This creates a "Requestor" and "Approver" audit trail, which is critical to this process. 
3. Alice marks the Table "Public - Can Download" in Synapse, which is additive on top of existing Sharing Settings. 
4. The Table becomes publicly viewable and the API for getting Table data is usable without logging in for the Community Portal components. 

This workflow is incredibly fuzzy right now because we're not sure what the approval process should look like for data or schema changes. A key assumption here is that a Table may be made private again by a Synapse user with permissions to change Sharing Settings. 

• Currently, we don't think that making it anon-public limits editing access; that is, a user can still change the table and save a new version of the Table. 
• Currently, opinions are mixed on whether changing the data and/or the schema will trigger a need for re-approval, but we should assume that this approval process may be cyclical.

Use Case 2: Anonymous Access to Data Stored in a Table (Delegated Process)

All the same things as Use Case #1 but for external groups – de-prioritized for now. 

Use Case 3: Anonymous Access to Data Deemed "Open Access" 

All the same things as Use Case #1 but for more kinds of data – de-prioritized for now. 

The broader general case is that Synapse currently does not support any kind of "Open Access" data, despite saying that we do, because we ultimately still have a login requirement to access (download) any data, even data marked for Open Access. This includes Files and Tables, and potentially other kinds of data later on. This limits the kind of content that can be shared in Wikis, which CAN be anonymously viewed, and we've implemented workarounds to this such as allowing anonymous access to files loaded as Wiki Attachments, but not those same files loaded as "Files" in the Files tab. This is incredibly confusing to users and actually introduces more risk than simply allowing (vetted) open access data, because there are no "checks" on data loaded into Wiki Attachments. 

Key issues here:

• Who assumes the risks? Need to be able to delegate approval so Sage/Governance is not a bottleneck, nor do we want to assume ALL the risk. 
• What is the process here? We presume we will iterate through these use cases in order, since we will learn a LOT about process during this exploration. 
• Assumption: if we can't make this work internally, there's no way we can make it work externally. Anecdotally, there is a lot of evidence that not supporting "Open Access" data puts us at a competitive disadvantage, and there are several feature requests related to this, listed below:
  • 
  • 
  • 
  •  

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Not Doing

• List the features discussed which are out of scope or might be revisited in a later release.