Hilary James Oliver

> I think this issue can be resolved simply by removing the use of the -force-remote option. However, this will need a bit of investigation to make sure we understand...

@dpmatthews - given @oliver-sanders' response there, I think making it configurable as per #509 is a reasonable solution for the moment, to give BOM what they need. With the proviso...

> There's no need for configuration here, we just need to invest the time to make any required improvements to cat-log such that the option isn't needed. > We should...

> The current thinking is that "live" data will be controlled by the n=x window (i.e. n=0, n=1, ...) and the "offline" data will be controlled by the n=cycle window...

I meant, perhaps historical data should not be full-cycle based by default when applied to our "live" workflow views (graph, tree, etc.), because that may overwhelm the browser. Other options,...

> (n=cycle previously discussed right?). Yes, but I'm not sure we decided it would be the default even for historical data. And even if we did, we'd have to revisit...

I just mean, if I have the tree view open (say) and I want to see the logs of a historic task, should that automatically populate the tree with whole...

> So requesting one cycle of historical data wouldn't mean that every view would show this "by default". The ability to display historical data would need to be enabled on...

Note the *Authorized Operations* User Profile div in @datamel's https://github.com/cylc/cylc-ui/pull/728 goes some way toward this, in that dashboard (and user profile) are relative to the target, not authenticated, user.

Also: release from runahead pool is currently used to trigger auto-spawning of the next instance of a parentless task. But we should be able to replace that with entry to...