Page Comparison

...

• Depending on the project need, portals can be driven dynamically from Views or , statically from Tables, or some combination via Materialized Views and/or Virtual Tables.

• External content that the portal renders within the site must be hyperlinked "https". Links out can be http or https.

• Sharing settings on Tables

  • Make Public - Anyone on the web, Can View.

  • All Tables (not Views) must be explicitly allowed anonymous access in order to be visible to anyone on the web (without logging in to Synapse).

  Removing facets can improve performance

  • Follow these steps, with authorization from the portal PI or department head, to whitelist the Table.

  • A change to ACL could disrupt visibility although, whitelist status is still maintained in the back-end.

Jira

Portal development coordination is tracked in the Community Portals Jira project. Create an appropriate Epic within the PORTALS Jira project to track the overall project. It is the job of the respective portal product manager to triage issues to the engineering team (Alina, Michael and Jay) appropriatelyappropriately.

Jay Hodgson is ultimately responsible for triaging and assigning design related issues, and portal engineering components.

What are the first steps?

...

1. Fill out the 1-pager for product and design and submit a Jira in the PORTALS project for review.

2. Open a Jira to task the design team with the creation of relevant wire frames. Designers will implement logo and color scheme. Depending on the level of customization or needs for external parties, a complete wireframe may not be required. This is at the discretion of the design team.

3. A Synapse Project drives the backend of the portal. Make a Synapse project (e.g. PEC).

...

1. Open a Jira issue with PORTALS to (e.g. PEC) create required infrastructure. This creates an empty AWS bucket.

2. Implement design in the staging site by opening a Jira issue with PORTALS (e.g. PEC)

...

{TODO:determine what is required to make these connections} Create Table/View architecture

...

Publications

1. Set schema

2. Tool to scrape Pubmed for relevant publications using grant or pubmed id as input

...

People

1. Set schema

...

Study

1. Set schema - note "hint text" is tracked in Confluence page and must be manually set by web developer

General notes about table schemas and column types

...

1. .

2. Create Tables and Views in Synapse to drive the Explore and Homepage components of portals. The names and number of tabs nested under Explore is customizable.
   Note - if you enable Full-Text-Search on Tables, the portal will surface this capability to the user.

   Image Added

3. Define the Tables and Views in Confluence pages or in the implementation Jira tickets. Be explicit about the Synapse entity to reference and the number of secondary fields to display in the cards. Secondary fields are defined in the UI Mapping /wiki/spaces/PEC/pages/844759171.

• Display Name - The Column Name will be the Display Name unless explicitly specified in the schema. If the Column Name is camelCase, it will automatically display as Camel Case.

• Column Name

• UI Mapping - Define the hierarchy of variables to display on the cards as title (e.g. Center for Cancer Systems Pharmacology), subTitle (e.g. Harvard University), description (e.g. The Center….), secondaryLabels[0](e.g. INVESTIGATOR), secondaryLabels[1] (e.g. GRANT NUMBER) etc.

  Image Added

• Destination - Note where a column should hyperlink to other resources within the portal.

• Searchable Y/N - (relevant only if Full Text Search is not enabled)

• Search hint text -

• Markdown Y/N - While simple markdown (links, bullets, bold, etc) is supported in underlying tables,

...

• explicitly specify which columns

...

• contain markdown in the schema

...

if you need to link to multiple synapse IDs, separate the list with commas

Setting Views and Tables

If you set a facet in a Table or File View, it will be displayed in the portal. It will also come at a cost - the more facets, the slower the performance.

Portals can be driven off of both Views and Tables. Key considerations when determining which to choose:

• By design, Tables are not public. Therefore, Portal Tables must be explicitly whitelisted by governance and someone on the leadership team in order to make them public. This is required any time the schema changes or values are added.

• Files are only available to bulk download through Views. (Bulk download feature not exposed in the web UI in Tables).

• There is potentially a performance hit in Views (in dispute; has not been fully tested) if there are varying access permissions across the set of files and many facets.

Use these questions to guide conversation with the design team about the homepage:

...

Why/goals/value- what is the focus of this portal

...

Relationship to consortium

...

Fit in ecosystem

...

Type of resources available

...

Diversity within type/amount within type

...

Main actions- e.g. find data/tools/people

...

Progress and future-- living repo/freshness of data

...

• .

Testing on Portals

1. Scenarios to test on staging when updating portals

2. For portals on a new *.synapse.org subdomain: verify that authentication state is shared between synapse.org and your portal

   1. Sign out of your Synapse account on your portal

   2. Sign in to your Synapse account on www.synapse.org

   3. Navigate to your portal (<portalname>.synapse.org). You should be automatically signed in.