ULIMS-50: Shipping service incoming shipment redirect

[MattPrit]

JIRA ticket: ULIMS-50

Depends on #698

Summary:

Adds the option to redirect to the shipping service to book shipments when booking an incoming shipment.

Changes:

• Adds feature flag $use_shipping_service_redirect_incoming_shipments which enables/disables this feature
• Reduce the number of fields in the create AWB form in the case of a domestic shipment when terms have been accepted
• On requesting a booking for an incoming shipment, create a shipment request in the shipping service and redirect to the appropriate shipment workflow to book a shipment
• If a shipment request has been created for the incoming shipment, display a 'manage shipment booking' button that links to the shipment request in the shipping service rather than to the 'Print Air Waybill' button.

To test:

• To display the new shipment view, go to an active shipment, accept the terms and conditions stipulated for shipping with Diamond's courier
• Check that the appropriate 'create awb' form is displayed for academic, domestic, industrial, international shipments
• Check that the appropriate shipment request is created in the shipping service when a user submits the form
• Check that the 'manage shipment booking' button links to the shipping service correctly once a shipment request has been successfully created

Note:

• Requires the addition of the externalShippingIdToSynchrotron column to the Shipping table in ispyb. Since the _get_shipments endpoint now attempts to return this column, a 500 will result whenever this endpoint is called without the new column having been added
• The changes contained in this PR (and LIMS-1113: Shipping service dispatch redirect #698) only result in shipping service redirects for domestic academic shipments that have accepted the shipping terms. All other kinds of shipment booking actions are still performed in SynchWeb. Since knowledge of a user's country is known ahead of the redirect, there is still a dependency on lab contacts containing addresses.

[gfrn]

Just so we have it in writing, what is the purpose of externalShippingIdToSynchrotron and why should it exist in both Dewar and Shipping?

[MattPrit]

Just so we have it in writing, what is the purpose of externalShippingIdToSynchrotron and why should it exist in both Dewar and Shipping?

externalShippingIdToSynchrotron exists only in the Shipping table, it holds the id of the entity in the external shipping service that corresponds to the booking of Shipping's Dewars to the synchrotron. externalShippingIdFromSynchrotron exists only in the Dewar table, it holds the id of the entity in the external shipping service that corresponds to the booking of each Dewar from the synchrotron. These columns are split across multiple tables because, while all Dewars in a shipment are shipped to the synchrotron together, they are dispatched individually. Alternatively, the externalShippingIdToSynchrotron column could be in the Dewar table, but the same id would be duplicated for each Dewar in the 'shipping'.

The required database change has now been made, see DiamondLightSource/ispyb-database#228

[MattPrit]

New things to test:

• Check that, when there is a shipping service 'shipment request' creation error when submitting createawb or dispatch forms, an error message is shown and a redirect is not perfomed
• Check that dispatching a Dewar with no defined outgoing lab contact is possible for domestic shipments when shipping terms have been accepted (i.e. hidden fields are no longer required)

[gfrn]

There is a possible non-issue, where if you manually delete the package description/shipping date, they cause validation to fail as they are still required, unlike all the other fields.

Not sure if this is an issue, since this would require users to deliberately "break" their own shipment, and I don't see a way this could happen during the "automated" process