Change how a product is priced prototype

"The desk says my Bermudan swaption price is off, so I want to price it another way. I also want to change two other products, and I want one sign-off for all of it." A product row belongs to a configuration that several reports bind. A change to it is a change to all of them, and a person who owns one report may not own the others. The edit dialog says that the change is saved to the working copy and reaches no run. The propose dialog shows the reach and the whole difference before anything is submitted.

• ?status=approved|draft: an approved configuration takes a working copy and a proposal. A draft changes in place, with no working copy.
• ?bound=0|1|4: how many reports bind the configuration. With none the dialog says the change reaches no run once it is approved. With one or four, it names them.
• ?saved=0|2: the working copy holds two saved versions, so the propose dialog shows a difference with two changes.
• ?pending=1: a proposal is already open. The working copy is locked, because the reviewers read it, and the person can withdraw the proposal to keep editing.
• ?conflict=1: the proposal is refused because a newer version became the version in force since the working copy began, with Reload.
• ?config=c1|c2&open=<product type> opens the dialog on a product.
• Changing the model marks the engine for review. A pair not known to work is marked, never refused.
• A setting the new pair does not take is shown as will be dropped with a Drop tick, and a setting the pair usually needs is shown as usually needed with an Add tick. Nothing is dropped or added until the person ticks it.

• Save to the working copy writes a saved version, numbered after the version in force (4.1, 4.2). A saved version has a change reason and a commentary of its own, so the person leaves a trail of what each step was for. It is in the History tab as Saved, and it is not in force.
• Restore in the working copy writes the data of an older version as a new saved version.
• Discard the working copy drops the saved versions and leaves the version in force as it was.
• Propose for review shows the difference between the version in force and the working copy, the saved versions it contains, the reach and one reason with a commentary, and submits one request. The sign-off is that of the existing sign-off prototype.
• The earlier design offered a proposal for each product row and a draft copy for one report. Both are gone. A proposal for each row makes the person sign off many requests for one piece of work. A copy for one report made a second unofficial configuration in the pricing of an official report, which model risk exists to stop.

Every value. The reports are names, because no read lists the reports that bind a configuration. The usual pair and the settings are the same fixture as the authoring prototype. A submit writes a proposal to the page's memory and marks the changed products with change proposed. The page cannot say which version of a configuration a run used, because no operation returns it, and it says so in the reach.

The evidence of a change is not drawn. A person will want to run a report with the old version and with the new one, and have the delta explained. The propose dialog says that this does not exist. It is the task Show the effect of a configuration change.

doc/prototypes/reporting/change-how-a-product-is-priced/index.html. One file, plain HTML, CSS and JavaScript, with the style and the script inline, no modules, no fetch and no build step.

• The History tab draws the shared timeline as the Entity screen specification draws it, with the saved versions of the working copy, the proposal and the versions in force in one stream.
• A person saves many versions and proposes once. The request holds the whole working copy.
• An approved version never changes in place. The page says what stays in force.
• The reach and the difference belong in the propose dialog, because that is where the one request is made.
• Nothing is dropped or added by the pair change until the person ticks it.

None yet. This page is on the branch that proposes it and waits for review.

• The lifecycle of a configuration: whether a proposal locks the working copy, who may see another person's working copy, and what happens when the version in force moves under a working copy. The page draws one answer for each. The task Research the configuration lifecycle decides them.
• Whether the history of a configuration should show a change to one product as the change of a row. The document write moves the version of the whole document.