feature request: "simpler" way of moving flight tracks between local flighttrack/operations

[joernu76]

The "work asynchronously" option is not being adopted. People want a "simple" way to copy a flighttrack from the operations pane to the "local flight track pane" and back.

In the operation->local direction a simple copy with the same name (and potentially a windows like (1)/(2) tag at the end) would do. In the local->operation direction one/two menu entries with "copy into new operation" "copy into existing operation" would do. The latter would require a dialogue for selecting an operation.

A bigger redesign could allow the selection of track on both sides with arrow buttons or similar, but I prefer the solution described above.

This would allow the removal of the "work asynchronously" button, which allows a very similar feature, but is not being adopted/understood by users on site.

[joernu76]

@soerenjoh

[ReimarBauer]

That is already implemented

The recent operation Revision could be exported to a ftml

And a ftml can become Imported to a new operation or to an existing operation.

When the operation exists the name of the ftml gets a name in the revision history.

The only thing missing is that an exported operation gets loaded directly in the left hand flighttrack list.

[joernu76]

I am aware of this. This is what people are doing.
We want this without using a local file as workaround.

[ReimarBauer]

We can only add it as 10.1.0 when we can add new API without changing existing API.

When we need a 11.0.0 we can also do this.

I assume when you only want to have it in the waypoint table without a state where it is worked on then still the operation is selected or the flightpath and all "Menu entries" Options have to take care for that state.

The work async back up all changes in a local file too.
$HOME/mss/local_colabdata/op_user/op_name/mscolab_operation.ftml

The simplest workaround maybe to set the mss data_dir to ~/mss/local_colabdata/ ?

[joernu76]

As we have a "workaround", this is not critical and need not (but could) be implemented for this campaign.
I selected 10.1 as I foresee an implementation sooner than later. We can discuss this when we have a merge request.

[ReimarBauer]

related #1632