Integrate LCO observing portal into the TOMToolkit workflow

[jchate6]

Rather than replicating all of the functionality very cleanly and nicely implemented by the OCS in the observing portal, the TOMToolkit should leverage this implementation.

iframe

Pros

• Fully embedded within TOM
• possible to pass information back to TOM
• Special Obs Portal iframe mode removing top Banners

Cons

• Awkward placement (need better control of iframe sizing)
• Double scroll is annoying, Obs portal has arbitrary length

---

Redirect

Pros

• All major changes on the OCS side
• Special redirect Obs Portal mode that pre-loads target/user data, changes top banner, and redirects back to TOM after submit.

Cons

• Disruptive. Need to Leave my TOM
• substantial OCS changes needed

---

New Tab

Pros

• Very easy to implement
• Could pass target, user, and post-submit redirect info

Cons

• Disruptive, Need to leave my TOM

[jchate6]

I have tried to capture the gist of our conversation, and added very rudamentary wireframes for what this might look like.
Can @phycodurus @Fingel and @jnation3406 please fill in any details, and feel free to continue the conversation here?

[Fingel]

One additional concern about the iframe approach is what happens once the observation is submitted. Since the OCS is on a separate domain, we can't access the location of the iframe from the parent frame. So it's not clear to me how we detect that an observation has been submitted. We want to detect once the observation has been submitted so we can redirect to the observation detail page.

With the full redirect approach, we can have the obs portal itself redirect to the observation detail page in the tom (using a kind of callback parameter passed by the TOM). If we did this within the iframe only the iframe would change location, not the entire page.

[jnation3406]

The iframe approach can send data between the iframe and parent using the postMessage API, so I think we can at least use that to transmit when a request has been submitted. But that would add more custom iframe code to the obs portal UI...

[Fingel]

Copying over the redirect PR description:

This is how this flow works:

User is at the TOM:

1. The facility class constructs a URL that points to the OCS. This URL contains query parameters that correspond to the chosen Target's attributes.
2. The facility class also constructs a callback url, which points to the internal tom_observations:callback view. This callback url contains query parameters for the facility class name, the target id, but leaves the observation id blank (this is to be provided by the observation portal)
3. The facility class simply presents a the combined link to the OCS (with the callback url appended as a query parameter). User clicks on the link to the OCS.

Now at the OCS:

1. The OCS presents the observation create form, and pre-fills in the target fields based on the query params.
2. The user submits the observation.
3. Instead of doing whatever the OCS does, it redirects to the callback url created in the previous step 2 with the newly created observation_id appended.

Now back at the TOM:

1. The callback url creates an ObservationRecord object from the query parameters passed in from the OCS: target_id, facility, and observation_id.
2. The user is sent to the ObservationRecord detail view of the newly created observation record. There is no distinction between records created using the built in OCS form or those created via the redirect flow.

[Fingel]

The implementation for this story is spread across 3 repos in 3 different orgs. Placing them here for reference:

LCOGT/observation-portal-frontend#133
observatorycontrolsystem/observation-portal#345
#1357