Screensaver Reference Topics

1. Running SQL scripts and cache clearing
   1. Manually clearing the API cache:
2. ICCB-L Screener Data Sharing Rules
   1. Effective User-Screen Data Access Levels
   2. User-Screen Data Access Level Matrix
3. ICCBL Authorization implementation
4. Request Background Processing
   1. Background process sequence
   2. Background processing settings
5. Screener User Manual

Running SQL scripts and cache clearing

The Screensaver server caches the result of certain requests to enhance the performance of the web application. When identical subsequent requests are received, Screensaver will serve the response from the cache instead of querying the database again.

Screensaver manages the clearing of this cache as a part of data update processes performed through the API. This cache is persistent; caching entries are stored in the database, so the cache will be available after the server is restarted, and the same cache is available to all server instances.

If data updates are performed directly in SQL, the cache will not be cleared, and the updates will not be shown for requests made through the API. To fix this, the cache must be cleared manually after SQL updates.

Manually clearing the API cache:

• Log in to the Screensaver web application
• Visit the URL (e.g.):
  • https://screensaver.med.harvard.edu/reports/api/v1/resource/clear_all_caches
  • this URL has the form https://<server_name>/reports/api/v1/resource/clear_all_caches

ICCB-L Screener Data Sharing Rules

Data access permissions for screener accounts at the ICCB-L are defined by data sharing agreements.

• Small molecule Screen data sharing is defined in the ICCB-L Small Molecule User Agreement
• Functional genomics Screen data sharing is defined in the ICCB-L Functional Genomics User Agreement

Effective User-Screen Data Access Levels

Screensaver determines the visibility of Screen data to a Screener by calculating the “Effective User-Screen Data Access Level” for each Screener user with each Screen.

(permissions for each level include all lower level permissions)

User-Screen Data Access Level Matrix

( for users with qualifying data deposited)

ICCBL Authorization implementation

The Authorization classes that are assigned by default are set up for the ICCB-L Screening Facility. These assignments are as follows.

UserGroupAuthorization The default class controlling Staff user permissions. Authorize users based on User and Group assigned permissions.

LibraryResourceAuthorization

• Write permission is determined using UserGroupAuthorization.
• Read permission is granted to all authenticated users.
  • Only Staff may view Libraries that are not “released”

ReagentResourceAuthorization

• For Well and Reagent views
• Same permission assignents as LibraryResourceAuthorization

ScreenAuthorization

• Control access to Screen and Study Resources
• Override UserGroupAuthorization to give screeners permission for restricted read access to screens they are authorized to view.
  • Screener authorization is determined by the ICCB-L Data Sharing Rules

ScreenResultAuthorization

• Control screener access to screen result data as defined by ICCB-L Data Sharing Rules

DataColumnAuthorization

• Control screener access to screen data column information as defined by ICCB-L Data Sharing Rules

TODO: How to override default authorization with AllAuthenticatedWriteAuthorization (Or AllAthenticatedStaffWriteAuthorization) for ScreenResource, LibraryResource, etc…

Request Background Processing

Many HTTP Requests can require more time than the HTTP server will allow to process the request before streaming a response back to the client. Such requests are handled as “background jobs” by Screensaver.

Background process sequence

• When the server recieves a background job request
  • a Job entry is created and a Job ID is returned immediately to the client.
  • Simultaneously, the server will fork a subprocess on the webserver operating system.
• This subprocess will spin up a separate special server instance and recreate the request on to this instance.
  • This special server instance will record status to the Job entry, and
  • will write the request response to the filesystem when finished.
• At any time after the initial request, the client may query the Job status using the Job ID.
• when the Job status is complete, the stored response may be retrieved.

Background processing settings

    BACKGROUND_PROCESSING = True
    APP_PUBLIC_DATA.BACKGROUND_PROCESSING = BACKGROUND_PROCESSING

    BACKGROUND_PROCESSOR = {
        SCHEMA.SETTINGS.BACKGROUND.POST_DATA_DIR: os.path.join(
            PROJECT_ROOT, "..", "logs", "background", "post_data"
        ),
        SCHEMA.SETTINGS.BACKGROUND.JOB_OUTPUT_DIR: os.path.join(
            PROJECT_ROOT, "..", "logs", "background", "job_output"
        ),
        SCHEMA.SETTINGS.BACKGROUND.RESPONSE_DATA_DIR: os.path.join(
            PROJECT_ROOT, "..", "logs", "background", "response_data"),
        SCHEMA.SETTINGS.BACKGROUND.RESPONSE_DATA_DIR_MAX_BYTES: (2**30)*1, # 1GB
        SCHEMA.SETTINGS.BACKGROUND.MAX_JOBS_PER_PERSON: 3,
        "credential_file": os.path.join(
            PROJECT_ROOT, "..", "production_data", "credentials.txt"
        ),
        "python_environ_script": os.path.join(PROJECT_ROOT, 'scripts', "run_webconf_consolelogs.sh"),
        "background_process_script": "reports.utils.background_client_util",
        }

Screener User Manual

For usage of the Web client application, see the Screener User Manual.

Table of contents

• Data Interchange