Users should not need to know about insertion (or task proxies generally)

[hjoliver]

We should probably generalize the ideas behind #774 (and the aborted PR #2027) - auto-insertion on restart and reload, and #423 (comment):

The fact that task proxies have to be present in the task pool before you can do anything with the tasks they represent is really an aspect of internal implementation that should be hidden from users as far as possible:

• if you try to trigger (etc.) a task that is not present in the pool, its task proxy should be auto-inserted and then triggered (etc.)
• the GUI tree and dot views should show all task names for all active cycle points even where there are currently no corresponding task proxies (c.f. graph view "base nodes"). Then users can right-click trigger (etc.) on those tasks too. This would also make the GUI text tree view more static/stable - easy to continue monitoring the same place in a large active suite.

[hjoliver]

For a partial interim measure we could just do an auto-insertion for trigger commands (etc.) if the target task proxy is not in the pool.

The second point above (GUI) would presumably require either asking the graph for all the tasks valid at a particular cycle point, or iterating through all proxies in the pool and asking if the target point is valid for each. The first method might be a natural fit for our plans to move away from task self-spawning to graph-driven spawning: see #987 (comment).

[matthewrmshin]

Some what related. A user has asked for an easy way to insert the previous cycle of a task via the GUI.

[hjoliver]

A user has asked for an easy way to insert the previous cycle of a task via the GUI.

The graph view right-click menu has an "insert ..." option, that populates the insert task dialog with task name and cycle point - so it's easy to change the cycle point to the previous one there. (I think this menu item used to appear on ghost nodes - which would make more sense - but we seem to have disabled the right-click menu entirely on them)

[hjoliver]

From an email discussion involving @matthewrmshin: this should be extended to instantiating future task proxies just for querying their properties with commands like cylc show. In this case, the task proxy should be instantiated, queried, and deleted - not added to the task pool.

[matthewrmshin]

A user reported a similar use case when trying to hold all tasks in a cycle. The user assumed that by right clicking a cycle in tree view and selecting Hold, it would hold everything in the cycle from then on. In actual fact, it only held the tasks in the cycle that were in the task pool at the time. The user was a bit surprised when some tasks in (supposedly held) cycle ran later.

[hjoliver]

Ah yes, that's an interesting side effect of this problem.

[hjoliver]

This should be solved by the "hybrid model" that makes our current task pool look like our future spawn-on-demand internals.