# prs-toolkit

***Performance Rights Services Tool Suite***
--

# Links

- [`prs-toolkit`](https://github.com/theorchard/prs-toolkit/tree/master) on GitHub
- [Deploy job](https://pipeline.theorchard.io/job/theorchard/job/prs-toolkit/job/master/) on Pipeline | [Build job](https://pipeline.theorchard.io/job/theorchard/job/prs-toolkit/) on Pipeline
- [User definition / privs](https://github.com/theorchard/python-rds-utils/blob/master/lambda/sanitise_rds_data/scripts/qa-art-relations/users.sql#L1537-L1549) for QA Art Relations
- Deployed targets
    - [QA PRS Toolkit](https://qa-prs-toolkit.theorchard.io/)
    - [Prod PRS Toolkit](https://prs-toolkit.theorchard.io/)

# Description

This toolkit aids Performance Rights Services team members in daily operations. The toolkit is separated into two primary uses, with related sub-sections and tools therein.

## Heuristic Client File Processing

- **Performance Rights Research Tool**
- **Claims Processing**

These two apps are really tool **sets;** each set comprised of two related systems.In each instance of the app, Claims Processing or Performance Rights Research, the two components work in tandem.

The first of the two component systems accepts incoming statement files of pre-determined shapes from various sources, and automatically processes them asynchronously, filling in whatever information is missing in the input files using a series of increasingly broad heuristic searches against `art_relations`. Any searches that return a single match are written to the file. Any searches that return no results after the heuristic plan is complete are marked as `NO MATCH`. Any searches that return a set of potential matches — under a certain sanity threshold — have those results stored in a `solution_table` for PRS team processing

The second component system provides an interface to display the potential matches for any file after the automatic processing is completed. This interface gives the PRS team members a fast and focused interface to assign Orchard track Id’s to incomplete incoming metadata.

## **Ad-Hoc Tools**

- **Useful Search Tool**
- **Update Track AND Label Delivery History**
- **Generate Society XML**
    - **SCPP XML Tool**

These are various ad-hoc tools for day-to-day PRS team operations.

The useful search tool is the pre-cursor of the Heuristic Client File Processing tools above, and as such, shares some of its functionality. 

### Useful Search

Allows for more precise and focused backend Art Relations searching than is available in existing user-facing tools.

### Update Track AND Label Delivery History

Allows for the logging and tracking of track deliveries made to various P.R.O.’s

### Generate Society XML

Allows for the generation of filtered catalog metadata delivery files targeted for specific P.R.O.’s. 

<aside>
⚠️

This tool is currently limited to Australia - PPCA by PRS team request.

</aside>

### SCPP XML Tool

Generates filtered catalog metadata `.xml` files for delivery to SCPP using SCPP’s proprietary logging system, in the SCPP XML spec.

## **Tool Logs**

- **Performance Rights Tools Log (Last 50 Tool Runs)**
- **Latest Runs**
    - **Show Latest Tool Run Only**
    - **Show Last 5 Tool Runs Only**
- **SCPP XML**
    - **Show SCPP XML Tool Only**
    - **Show Latest SCPP XML Tool Run Only**
- **Society XML**
    - **Show Society XML Tool Only**
    - **Show Latest Society XML Tool Run Only**
- **Delivery History**
    - **Show Delivery History Tool Only**
    - **Show Latest Delivery History Tool Run Only**

These are user-facing log views to track processes and receive payloads from async or long-running (i.e. metadata generation) processes.

## RDS Aliases

- [research-collections.theorchard.com](http://research-collections.theorchard.com/) is an alias for [prod-prs-toolkit-db.theorchard.io](http://prod-prs-toolkit-db.theorchard.io/).
- [prod-prs-toolkit-db.theorchard.io](http://prod-prs-toolkit-db.theorchard.io/) is an alias for [prod-prs-toolkit.cluster-cb22xqmk0y0q.us-east-1.rds.amazonaws.com](http://prod-prs-toolkit.cluster-cb22xqmk0y0q.us-east-1.rds.amazonaws.com/)
- [prod-prs-toolkit.cluster-cb22xqmk0y0q.us-east-1.rds.amazonaws.com](http://prod-prs-toolkit.cluster-cb22xqmk0y0q.us-east-1.rds.amazonaws.com/) is an alias for [prod-prs-toolkit-0.cb22xqmk0y0q.us-east-1.rds.amazonaws.com](http://prod-prs-toolkit-0.cb22xqmk0y0q.us-east-1.rds.amazonaws.com/)
- [prod-prs-toolkit-0.cb22xqmk0y0q.us-east-1.rds.amazonaws.com](http://prod-prs-toolkit-0.cb22xqmk0y0q.us-east-1.rds.amazonaws.com/) has address 10.100.31.143

## Stack Versions

As of 2024-11-12

- Docker container: `debian-8.2`
- MeekroDB: `3.1.1`
- Sentry: `3.18`
- MySQL Connections enforce: `utf8mb4`
- XDebug:  `3.4.0b1`

# Special patterns

- Ajax(jQuery) + PHP
- Async MySQL Calls via executed via cronjob
- XDebug 3.4.0b1 available in the repo for local development
- File Uploads / Downloads stored on mounted storage
- Self-contained tracking tables for comparison against `art_relations`

# TODO

- Code refactors needed all over the place.
- Better analysis of end-user use-cases to cull / improve services.
- Confirm/restore functionality for Statements Research Processing (CC: Becca Garcia)
- Add more infra / service links from Slack chats with Tanzeel or #prs-toolkit channel to this doc.
- Describe Active Tools
-

## Old Readme
This is the Performance Rights Services Toolkit, a collection of tools for working with Performance Rights (and other) metadata files.

# Development Configuration

## Prerequisites
- Docker
- Docker Compose
- PRS RDS Access
- ReportsAR DB Access

## Running the application
1. Clone the repository
1. Copy the `.env.shadow` file to `qa.env` and fill in the required values
1. Run `awsume <role>` to assume the correct role for access to our Prod AWS ECR repository
1. Run `aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 086679231553.dkr.ecr.us-east-1.amazonaws.com` to give docker access to the protected image we'll be pulling down.
1. Run `docker compose -f docker-compose-dev.yaml up --build` to start the application in development mode. (Includes [**XDebug**](XDebug Configuration) and `phpinfo.php`)

## XDebug Configuration
### XDebug Installation
When pulled from the `theorchard/prs-toolkit` repository, this application comes ready to send XDdebug requests. The `xdebug.ini` file and the `xdebug` extension are already included in the `deploy/dev` directory. The `docker-compose-dev.yml` file is already configured to mount the `xdebug.ini` and the `xdebug.so` files to the correct locations in the container.

### XDebug Use
Xdebug use is beyond the scope of this document, but the `xdebug.ini` file is configured to send XDebug requests to the host machine on port `9000`. The `docker-compose-dev.yml` file is configured to expose this port to the host machine. The XDEBUG_SESSION cookie is set to `devorch` by default, but this can be changed in the `deploy/dev/xdebug.ini` file along with any other settings.

*Don't forget to set your IDE to listen for XDebug requests on port `9000`, and to set the `XDEBUG_SESSION` cookie to `devorch` in your browser either through passing it as a query parameter or setting it in your browser's developer tools!*

### Environment Configuration
Copy the `.env.shadow` file to `qa.env` (or named to your liking) and fill in the required values. Ensure that the `docker-compose-dev.yml` file is configured to use your `qa.env` file.

### Production Deployment
All dev configurations are mounted dynamically from `deploy/` folder, with directives stored only in the `docker-compose-dev.yml` file. The `docker-compose-dev.yml` file is not used in production. and the `deploy` folder is deleted from the production image.

## PHPinfo
`phpinfo.php` is copied to the root of the application for debugging purposes via the `docker-compose-dev.yml` file. This file is not included in the production image.

To access the PHPinfo page, you must add your ip address *as seenby the docker image* to the `deploy/apache2.conf` file. I have not had luck with magic hostnames like `docker.for.mac.localhost` or `host.docker.internal` in the past, so I recommend using the actual IP address of your machine on the docker subnet. This is usually easily found in the logging of http(s) requests to the apache server.

```
<Location /phpinfo.php>
    Require host localhost, 127.0.0.1
    Require ip <YOUR_IP_ADDRESS>   <---- Add me
</Location>
```
