David Watkins

How about the **first Thurs of every month** (starting 2024-05-02). We do have some interest from some other banks (US based) so not sure how we can balance the timings...

Possibly shifting the first session back a week or two to accommodate Bank Holidays. Will post here once the dates and cadence have been confirmed.

Calls have resumed - closing this issue

Probably don't want to do this as a custom one-off change as it breaks the current ways that filters are implemented and would lead to a lot of bespoke code...

We should look to enforce minimum versions on our node/npm builds, see : https://stackoverflow.com/questions/29349684/how-can-i-specify-the-required-node-js-version-in-package-json We should also review the minimum maven version (currently enforced in the root `pom.xml` file)

Some basic investigations: ```javascript serviceBroker.loadAppData(CORE_API.MeasurableStore.findAll) .then(r => { global.raw = r.data; global.all = _.concat( [ {id: -1} ], _.filter(r.data, m => Object.assign(m, { parentId: m.parentId == null ? -1 :...

Bumping this back up as may give us an easy performance boost

Main problem will be reconciling the d3 strict _tree_ approach (single root) with the _forest_ approach used by Waltz (multiple roots). This can probably be overcome by using a 'fake'...

The WIP PR linked to this issue has a rough n' ready prototype for the measurable trees (i.e. on the viewpoint pages). On my mac it's showing a 4-5x speed...

The time discrepancy may be to do with the (deep) cloning performed in the current implementation. This may be excessively defensive.