Content Management

Version Control Tables and Views

Portal content is generally managed by Synapse wikis, Tables and Views. Optionally, Tables and Views can be version controlled.

A resources.ts file in the portals repository tracks the synId and respective version for each each portal component (example PEC).

To update the content on the live site:

Use the Create a New Table/View Version feature in Synapse under Tools to add a version to your synId using dot notation.
Open a pull request (PR) in the portals repository with the proposed change to the version number (example PR).
Once merged, the staging site will update. Validate changes.
Notify the platform team (via Jira, or some other mechanism) to push the staging site to production. Additionally, be mindful of changes the platform team might also have set-up on staging.

Configure facets

Making views publicly viewable

Synapse has a variety of entities, including files, tables, (regular) views and materialized views. Entities have data and metadata. For a file, the “data” is the file’s content. For a table, the “data” is its row/column contents. Entity metadata includes system attributes like entity name, creator, creation date, and user defined attributes, i.e., “annotations.”

Permission to access data and metadata are separate in Synapse’s sharing settings: Permission to see metadata is View permission while permission to get an entity’s data is called Download permission.

Synapse’s original design allows you to make metadata anonymously accessible (accessible to “Anyone on the web”) but does not allow you to make data anonymously accessible. The “Open Data” feature was added later to support the few cases in which data must be anonymously accessible.

What can make the above a little complicated is that a view is a tabular representation of the metadata of a collection of entities. So while the tabular content of a “table” is considered to be “data”, the tabular content of a view is considered to be “metadata”. You can make a view anonymously visible by giving the “Public” the “View” permission to the view and also the “View” permission on the items included in the view. Since the content is “meta data” rather than “data”, there is no need to configure anything (the view or the underlying files) as Open Data.

In an example issue, there is a “materialized view” (syn51581771) which pulls from a “view” (syn51232596) that displays metadata from a collection of “files”. To make the materialized view anonymously visible you need to make it publicly viewable, then make the view it draws from also publicly viewable, and finally make the entities in the view publicly viewable. It’s not necessary to configure any of this as Open data.