User Journey: Export to share with support

"I want to send support exactly what shows the problem, and no more." The journey is done when the person has a small file set, a short note that says what each file is, and a ticket that carries both.

The actor is any signed-in person who can read the data that shows the problem, usually an operations user. The trigger is a support ticket, a failed report, or a question about a convention that needs a concrete example. The journey starts at the ticket and ends when the attachment is on it.

The export reads only what the session may read. A book whose rights exclude the person cannot be exported, and the server refuses rather than returning an empty file.

1. Reduce the scope. The person picks one book or portfolio, one report definition, or one series. A whole party is usually too much, and the ticket rarely needs it.
2. Export the trades. The person runs ore export <file> --node-id <id>. The system exports the trades under that node as ORE portfolio XML.
3. Export the run. The person runs ore export-run <report_definition_id> <dir> when the problem is a report. The system writes the run document and every configuration document it binds.
4. Export the market data. The person runs marketdata export --market-data <file> --fixings <file> when the problem is a quote or a fixing.
5. Name the parts. The person writes a short note: the party, the node or report definition, the time, and what each file is. No command writes this manifest.
6. Attach to the ticket. The person attaches the files and the note to the ticket by hand. There is no attach action in the product.

The shell prints the number of trades and the bytes written, or the stored files of the run, or the series and observation counts. The files open in an ORE reader and in the platform's own importer. The ticket holds the files and the note.

An export with no read permission is refused and says so. An export of a node the person cannot see returns no trades or a refusal, depending on the read. A write to a path the person cannot use fails with the path named. An export of a report definition that binds a configuration type the exporter cannot write is refused. The person can still attach the failure message itself.

• The export must never include rows the person cannot read.
• The export must never be presented as a complete backup. It is an ORE-shaped file set with no audit columns and no history.
• The export must never write into the platform. It returns text to the caller's file system.
• The person must never be told the ticket received the files automatically. The product does not talk to the ticket system.

There is no export screen and no ticket integration. The entry points are ore export, ore export-run, marketdata export, and the person's own file system and ticket system. The web UI has no export route.

1. No bundle. The person exports several files and packs them by hand. Nothing writes one archive for the ticket.
2. No manifest. The party, the node, the time and the tool versions are not written by any export.
3. No redaction. A run directory carries whatever the run binds, and the person must remove the parts that are not needed. Nothing helps.
4. No ticket integration. The attach step is outside the product.
5. No export record. Nothing lists what the person exported and when.

• Reproduce a defect from an exported environment - what support does with the files.
• Export for archival - the complete version, with different intent.
• Diagnose and reproduce a failure - the failure the person is reporting.
• Import a portfolio from ORE - the receiving side.

• Trade journeys
• Conventions journeys

• Data exchange journeys - the group hub.