Sharing features ^Enterprise

Memgraph Lab provides Sharing features to enhance collaboration by allowing users to share queries and visualization styles effortlessly. These features enable teams to work together seamlessly, ensuring consistency in both queries and graph styling.

Here are the currently available sharing features:

• Graph Style Script (GSS) sharing – Share custom graph styling scripts among team members to maintain a consistent visualization style.
• Query sharing – Create a shareable link for their Cypher query, Graph Style Script, and query parameters with a single click.

Remote storage is required to use both sharing features.

Graph Style Script sharing

Graph Style Script (GSS) sharing is an Enterprise feature introduced in Lab 3.0, allowing users to share Graph Style Script among team members. This feature is only available in a Docker environment.

The Lab utilizes remote storage to securely store the scripts, ensuring sensitive information is protected and allowing easier collaboration.

Set up GSS sharing

For GSS sharing to function, the Lab requires a remote storage connection where GSS will be saved. Remote storage should be a new Memgraph instance or a new Memgraph database in a multi-tenant environment.

Having remote storage enables users to connect from different browsers to the same instance of Lab to see the same Graph Style Scripts.

This setup also allows administrators to connect to Memgraph, which acts as a remote storage, and access all users and Graph Style Scripts. Administrators can also perform migrations. It is essential to set up authentication and role-based permissions in Memgraph used as remote storage for the Lab to ensure data security.

Manage GSS in Lab

The Lab provides robust functionality for managing GSS, allowing users to create, save, and share styles for graph visualization. With the introduction of remote storage for GSS, users now have the flexibility to combine in-browser GSS with remote storage, tailoring their workflow to suit individual or team needs.

In-browser storage

In-browser Graph Style Scripts are stored locally in the user’s web browser. These scripts are accessible only within the same browser and on the same device where they were created or saved.

Key features of in-browser GSS:

• Save custom GSS: Users can create and save GSS directly in their browser.
• Load saved GSS: Any GSS saved in the browser can be loaded for use at any time.
• System default script: Load the system-provided default script for graph visualization.
• Custom default script: Designate any custom GSS as the default script to override the system default for that browser instance.

Limitations:

• In-browser Graph Style Scripts are device and browser-specific. They cannot be accessed from other devices or browsers.

Remote storage

Remote storage for GSS is a feature available as part of the Enterprise license. This option allows users to save Graph Style Scripts in a centralized storage system, enabling access from any device or browser connected to the same Lab instance.

Key features of remote storage GSS:

• Save and share GSS - Store GSS in the remote storage with flexible sharing permissions:
  • Private: Visible only to the creator.
  • Public: Accessible to any authenticated user connected to the same Lab instance.
• Edit shared scripts: Creators of a shared GSS can update its name, code, and privacy settings.
• Copy to in-browser storage: Users can copy a remote GSS to their browser storage, particularly useful for setting up a system default script.

Benefits:

• Centralized access to GSS from any location or device.
• Collaboration through shared scripts while maintaining privacy controls.

Combining in-browser and remote storage

The Lab enables seamless integration of in-browser and remote storage, allowing users to:

1. Use local and shared scripts: Access GSS stored locally in the browser alongside shared scripts from remote storage.
2. Switch between storage types: Decide whether to save and retrieve GSS locally or from the remote storage based on accessibility and collaboration needs.
3. Copy scripts across storages: Transfer a remote GSS to in-browser storage or vice versa, depending on the workflow.

Workflow examples

Individual workflow (in-browser focused):

• A user creates a custom GSS in their browser for personal use.
• The script is saved locally and set as the default for all graph visualizations in that browser.
• If the user moves to a new device, they will need to recreate or copy the script manually.

Collaborative workflow (remote storage focused):

• A team member creates a shared GSS in remote storage and sets it as public.
• Other authenticated users can access and use the script from their devices.
• The script’s creator updates it as needed, ensuring consistency across the team.

Hybrid workflow:

• A user saves a GSS in remote storage for collaboration.
• For personal tweaks, they copy the shared GSS to their in-browser storage and set it as the default on their device.
• The user can switch between the remote and local versions depending on the context.

Query sharing

Query sharing is an Enterprise feature introduced in Lab 2.15, allowing users to create a shareable link for their Cypher query, Graph Style Script, and query parameters with a single click. This enables seamless collaboration among team members. This feature is only available in a Docker environment.

The Lab utilizes remote storage to securely store the shared data, ensuring sensitive information is protected. Additionally, the system tracks which users viewed the query and when, providing comprehensive access logs for enhanced security and accountability.

Before using Query Sharing, make sure it’s properly set up. Once configured, you can learn how to:

• Create a query share
• View query share history
• Access and view a query share

Set up Query sharing

To enable the Query sharing feature in the Lab, you need to set up the remote storage (Memgraph instance) that the Lab will connect to and store query-sharing data and define users and their permissions.

Remote storage

For Query sharing to function, the Lab requires a remote storage connection where query-sharing information will be saved. Remote storage should be a new Memgraph instance or a new Memgraph database in a multi-tenant environment.

Remote storage is needed to keep all the information, such as the query, parameters, and other details, in the database, which can contain sensitive or private information. Only a share identifier is shared, ensuring data security. Additionally, having remote storage enables users to connect from different browsers to the same instance of Lab to see the shared query.

This setup also allows administrators to connect to Memgraph, which acts as a remote storage, and access all shares, users, and viewing history. Administrators can also perform migrations. It is essential to set up authentication and role-based permissions in Memgraph used as remote storage for the Lab to ensure data security.

User definitions and permissions

For Query sharing to function correctly, users should be defined in the Memgraph instance where the shares are created. This is the Memgraph instance that users connect to for running queries, not the remote storage Memgraph that Lab uses. This approach allows tracking of who viewed each query share and enables creators to manage their own shares.

Without user definitions in the Memgraph database, all connections are treated as the same user (Not-Defined user). This means everyone can see all query shares and potentially delete them from the history. Therefore, defining users in the Memgraph instance is essential for maintaining security and proper management of query shares.

Create a query share

A user can create a query share from the query execution editor. When a query share is created, the Lab stores information about the creator and all necessary details to run the query, including:

• Cypher query
• Graph Style Script
• Cypher query parameters

The creator can select which results view to display, either Data or Graph view. In the case of multiple queries in a share, the creator can also select which query results to show first. This is particularly useful when sharing a multi-query that involves setup queries followed by a graph algorithm whose results are to be displayed first.

Upon creation, the user receives a URL that can be shared with other team members who have access to the same Lab and Memgraph instance.

View query share history

Users can view a history of their created query shares, including the number of views each share has received.

The history will display all query shares created on the specific Lab instance. If you have created query shares for multiple Memgraph instances, such as production and staging, you will see both in the query history. To view a query share via share link as a viewer, you must be connected to the Memgraph instance where the share was originally created.

Users can delete any query share from the history. Once deleted, the URL associated with that query share will no longer be valid.

Access and view a query share

When a recipient clicks on the query share link, they must first connect to Memgraph. All the connection details will be prefilled on the login page, except for authentication data. Once the user is successfully logged in, they can view the shared query and choose to run it or save it to their collection.

Note that you cannot view a query share on a different Memgraph instance from the one where the query share was created.

Remote storage

The Lab utilizes remote storage to securely store the shared data, ensuring sensitive information is protected. Without remote storage, Lab stores data in the browser where it becomes hard to share your progress with your team members or in cases when you use the Lab from different location or different browser.

Remote storage works only in Docker environment and requires a valid Memgraph Enterprise license configured on the Lab side. The enterprise license will be checked once you set up the remote storage. Remote storage should be a new Memgraph instance or a new Memgraph database in a multi-tenant environment.

Using a standalone Memgraph instance as remote storage

In this scenario, Memgraph should be used only for Lab purposes to store query-sharing information. Memgraph can be a community or enterprise version. Make sure your Memgraph is running and then set the following environment variables so Lab can connect to it for remote storage capability.

These two environment variables are required:

These variables are optional and depend on the configuration of the Memgraph instance:

If your Memgraph instance has SSL defined and there is a username lab and password lab, the complete Docker command should look like this:

docker run \
  -p 3000:3000 \
  -e ENTERPRISE_LICENSE_ORG_NAME="My company" \
  -e ENTERPRISE_LICENSE_KEY="key..." \
  -e STORAGE_MG_HOST=127.0.0.1 \
  -e STORAGE_MG_PORT=7867 \
  -e STORAGE_MG_IS_ENCRYPTED=true \
  -e STORAGE_MG_USERNAME=lab \
  -e STORAGE_MG_PASSWORD=lab \
  memgraph/lab

If there is no username or password and Memgraph is accepting non-SSL connections, omit the optional environment variables:

docker run \
  -p 3000:3000 \
  -e ENTERPRISE_LICENSE_ORG_NAME="My company" \
  -e ENTERPRISE_LICENSE_KEY="key..." \
  -e STORAGE_MG_HOST=127.0.0.1 \
  -e STORAGE_MG_PORT=7867 \
  memgraph/lab

Upon successful configuration, you should see the following log output when starting the Lab:

INFO: [lab] Checking connectivity to remote storage *** with a timeout of *** ms...
INFO: [lab] Enterprise license applied successfully. Enjoy the premium features.
...
INFO: [lab] Remote storage *** successfully connected.

Using a Memgraph multi-tenant environment as remote storage

In addition to configuring the Memgraph Enterprise license in Lab, this scenario requires Memgraph Enterprise to be enabled on the Memgraph database, as multi-tenancy is an enterprise-only feature.

In a multi-tenant environment, you can use your existing Memgraph instance with a new database that Lab will use for remote storage to store information.

These three environment variables are required:

These variables are optional and depend on the configuration of the Memgraph instance:

Let’s say that you already created a new database called lab in your enterprise Memgraph instance for remote storage. For better security, it is recommended to always define usernames and passwords. However, if it accepts non-SSL connections with no username or password, the following command should make Lab successfully connect to the remote storage:

docker run \
  -p 3000:3000 \
  -e ENTERPRISE_LICENSE_ORG_NAME="My company" \
  -e ENTERPRISE_LICENSE_KEY="key..." \
  -e STORAGE_MG_HOST=127.0.0.1 \
  -e STORAGE_MG_PORT=7867 \
  -e STORAGE_MG_DATABASE_NAME=lab \
  memgraph/lab

If your Memgraph instance has SSL defined and there is a username lab and password lab, the complete Docker command should look like this:

docker run \
  -p 3000:3000 \
  -e ENTERPRISE_LICENSE_ORG_NAME="My company" \
  -e ENTERPRISE_LICENSE_KEY="key..." \
  -e STORAGE_MG_HOST=127.0.0.1 \
  -e STORAGE_MG_PORT=7867 \
  -e STORAGE_MG_IS_ENCRYPTED=true \
  -e STORAGE_MG_USERNAME=lab \
  -e STORAGE_MG_PASSWORD=lab \
  memgraph/lab

Upon successful configuration, you should see the following log output when starting the Lab:

INFO: [lab] Checking connectivity to remote storage *** with a timeout of *** ms...
INFO: [lab] Enterprise license applied successfully. Enjoy the premium features.
...
INFO: [lab] Remote storage *** successfully connected.