Rollup refreshes topic values but parent property not updating ...

  • 1
  • Problem
  • Updated 4 months ago
  • (Edited)
The map in question features a number of rollup topics from a single source map. Each source topic contains a property value. Their rollup equivalents in the destination map refresh as expected, every time, whether via menu command if the destination map is already open or automatically on opening the destination map (if that option is checked).

However ...

On the destination map these rollup topics are children to parent topics. The parent topics have forumulae which reference the subordinate rollup topic values. But the parent calculations are not responding immediately, as expected, to changes in the rollup children's property values. The parents only update by closing and reopening the destination map.

I've checked the references in the parent formulae and they're fine. 

Does anyone know what might be going on here and how to fix it?

Many thanks.

David A.
London
Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes

Posted 5 months ago

  • 1
Photo of Ary Velstra, Expert Trainer

Ary Velstra, Expert Trainer

  • 1514 Posts
  • 226 Reply Likes
Suggestion: could you include some visuals (or even a small video) to give us better insight?
And also What version do you use.
Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Ary,

Thanks for your swift response. It seemed only polite to acknowledge right away, before providing the further detail you requested. Back soonest ...

Best wishes,

David


Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Ary,

Hello again.

So here's 4-minute video of the rollup problem I'm seeing with MM 2019:

https://vimeo.com/user93283481/review/308584232/5f3c24d39e

Many thanks for your interest.

Best wishes,

David


(Edited)
Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Apologies if your earlier attempt to view the video was met with the Unavailable message. It's now on Vimeo. I hope this works okay!

https://vimeo.com/user93283481/review/308584232/5f3c24d39e

Again, many thanks for any insights you (or anyone) may have into the rollup issue described ...

Best wishes,

David A.
London


(Edited)
Photo of Alex Gooding

Alex Gooding, Champion

  • 1025 Posts
  • 250 Reply Likes
Hi David,

I can’t see either of the videos you’ve posted, but I’ve reproduced the scenario from your description with similar results.

I think this is a definite bug, as I can reproduce the behaviour you describe if I roll up individual branches from the source map to the destination dashboard map. When I do this refreshing the roll-ups after the numbers in the relevant topic properties are changed in the source map has no affect on the total shown on the central tropic of the dashboard map, and the only way to get it to update is to close and reopen the dashboard map.

If however I roll up the whole source map by basing the roll-up on the central topic, the dashboard map behaves as expected, ie, refreshing the roll-ups after the changing the topic properties updates the total in the central topic of the dashboard map. Interestingly the dashboard map regards the central topic of the source map as being a roll-up, even if it isn’t designated this way in the source map.
Photo of Ary Velstra, Expert Trainer

Ary Velstra, Expert Trainer

  • 1514 Posts
  • 226 Reply Likes
I have been playing around with it a bit and it seems that the order what you did first and what next etc. is influencing the result.

If I created the formula for total in the central map before I created the rollups. Your behavior appears.
When I create the rollups first and next the total formula in the maintopic. It works.

Test it as this may help in solving the issues.

by the way I tested on MM2019 for windows
(Edited)
Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Hi Alex and Ary,

Many thanks indeed for your spending time on this. It is certainly more than helpful to have corroboration from you both.

I tried Ary's test with an entirely new pair of maps: no joy - just the same error.

Can we assume that the MM tech team will react to our posts or should I create a ticket?

If it helps the tech team to justify addressing the problem, here is the issue exemplified by an actual use case from my current work, somewhat disguised. The bug creates real practical problems.

1. The destination map for roll-up purposes is actually the first map to be created. It is a right-hand map which defines/specifies a product: the final assembled and costed product is the central topic. Multiple contributors help to define the features and benefits to be delivered by a nested set of costed sub-assemblies and sub-sub-assemblies. The process is iterative based on the evolving consolidated cost-benefit picture, so that it would be truly disabling to leave all the formulas out until the spec is locked down.

2. Once the spec is finalised, the primary sub-assemblies (i.e. lowest-level inputs in the spec map) are copied into a set of product development timeline files. These comprise timed tasks which follow a substantially different logic from the specification map (i.e. they are work breakdown structures). Progress/budget indicators against the duplicated sub-assemblies are updated as work proceeds towards completion of each development strand.

3. It is then necessary to maintain perspective on how progress against the distributed development tasks is moving towards fulfilment of the overall desired product specification. To achieve this back on the specification map, the primary sub-assemblies on this map are replaced with rollups of their duplicates which now reside in the separate set of development plans. This should mean that changes and refreshment of the rolled-up properties in the development plans will trigger a trouble-free recalculation of all the upstream calculations on the 'master' specification map right up to the central topic, as if those changes had been made to normal (non-rollup) property values on this map. As you gather, this isn't happening as it should.

4. For a sense of scale in this real example, there are 65 primary input items to be rolled up between the development maps and the 'master' specification map. The specification map has 40 intermediate calculations, in addition to central topic consolidation, based on various aggregations of properties in the 65 primary inputs. Only these primary inputs figure in the development maps. [It would make no sense to add all the intermediate calculations from the specification map to the development maps as a workaround. Firstly, the radial layout of the former cannot be be replicated meaningfully in the event-line layout of the latter - and secondly the development maps would end up way too cumbersome and confusing.]

Again, thanks for your thoughts, Alex and Ary. Let's hope that this MM2019 bug can be fixed!

Best wishes for the new year,

David
London




(Edited)
Photo of Ary Velstra, Expert Trainer

Ary Velstra, Expert Trainer

  • 1514 Posts
  • 226 Reply Likes
Make a support ticket and please keep us posted
Photo of Alex Gooding

Alex Gooding, Champion

  • 1025 Posts
  • 250 Reply Likes
Hi David,

I agree with Ary that you should raise a support ticket regarding this.

I've played with rolled-up formulas further and cannot find a workaround. Unless the central topic of the source map (which means, in effect, the whole of the source map) is rolled up in the destination dashboard map, any formulas in the destination map relating to topic properties in the source map will only refresh when the destination map is saved and reopened.

And as you indicate, in most cases rolling up the whole source map kind of defeats the purpose of a dashboard map, while having to save and reopen the dashboard map is hardly an efficient way to manage things. Interestingly the same problem occurs with dashboard roll-up maps made within the source map, as well as in separate destination maps.

This is a fundamental fault which really limits the effectiveness of dashboard roll-up maps. It is the second problem I've come across with them; the first is the inability of dashboard maps to deal with user-defined tag and marker groups, though unlike the formula problem there is a workaround that can overcome this, albeit a fairly clumsy one.
(Edited)
Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Hi Alex,

Thanks for your further work on this odd bug.

I've also discovered that, once having freshed the rollup values in the destination/dashboard map, the dependent dashboard computations respond if you go into Map Settings in the same map's tab and toggle any one of the three newly introduced Renumber/Recalculate filter options.

Presenting my clients with an MM file as a finished work product, with an accompanying description of the bug in a critical feature and the arcane way of dealing with it, is not a great confidence builder all round. There is a risk that a subsequent client-side user who has not been briefed on the issue may assume that the dashboard's dependent values have been updated, when in fact they haven't. So then we're into posting a warning note on the face of the map, which is not great either ...

Hopefully Corel can address this issue swiftly. I'll keep you and Ary posted.

Best wishes,

David A
London
Photo of Alex Gooding

Alex Gooding, Champion

  • 1025 Posts
  • 250 Reply Likes
Hi David,

One way to make this process a little easier for end users would be to write a macro to toggle the Renumber/Recalculate options. This would just be a basic switch but you could give it a more relevant name as well as its own entry and tab group on the ribbon. You would of course have to install the macro on all the end user computers.

Unfortunately I’ve never really played with MindManager macros so I can’t help you to write one, but if you search the forum for posts regarding macros you will come across the names of people who could assist you.
Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Hi Alex,

I have some experience of macros in MM and, yes, one might be able to create a toggling macro by way of workround. Even then, one would have to issue a clear cautionary instruction - and intermittent troubleshooting of macros on the fly will not be at all obvious to non-expert users. (As you may know, there has also been ambivalence at MM about sharing the current API for quite some time. As MM features have evolved, so non-availability of the latest API has made macro creation that bit more challenging and laborious for most of us.)

All that said, I feel that while macros can be great to add or streamline custom functionality for power users, we should not be expected to rely on them to address basic (i.e. unintended) glitches. Here's the rationale in the present case:

1.  It is now a basic expected feature that dependent MM formulas should update automatically when any input value changes on a map.

2.  It is entirely reasonable to assume that a rollup value should count and operate as an input value, just like any other.

3.  Corel has expressed its strategic commitment to dashboarding, i.e. MM as a dynamic information management hub.

4.  It is unthinkable that such a critical feature should then be hobbled by the performance inconsistency in rollups which we seem to have unearthed - not to mention the added confusion of the menu option to 'Refresh Map Roll-ups on Open', when closing/opening is one of the workarounds to refresh the entire map, if this option is not selected and provided you already refreshed the rollups manually!

Unless we're really missing something here, we have to believe that Corel will fix the issue.

Will report back as promised.

Best wishes,

David A
London
(Edited)
Photo of Alex Gooding

Alex Gooding, Champion

  • 1025 Posts
  • 250 Reply Likes

Hi David,

I agree with you entirely - I was just suggesting a macro as a temporary and admittedly not very satisfactory workaround.

I think you have summarised the situation well. If you do end up getting someone at Corel to pay attention you could ask them to address the other dashboard map problem; the poor handling of tag and icon groups found in source maps.

Incidentally I am also concerned at your comments regarding the ambivalence at MM about sharing the API. I'm not a developer but the existence of an open API has obviously led to the creation of wonderful add-ins such as MAP.

Good luck with it and please report back.

Cheers

Alex


Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Well, it seems that the well-timed Service Pack 1 (MM 19.1.198) has recognised and resolved the issue, which is great news. Certainly my earlier problem files just cleared without a glitch. Trust you'll find the same.

Best wishes,

David

Photo of Alex Gooding

Alex Gooding, Champion

  • 1025 Posts
  • 250 Reply Likes

Hi David,

Thanks for reporting back. I can confirm that this works, at least for the simple dummy dashboard I created to test it. This will make rollup dashboard maps a lot more useful.

Unfortunately, the problem I reported with user-created tag and icon groups not appearing in dashboard maps has not been addressed, I suspect because there are a few more issues involved. Incidentally the only way to import these groups to a dashboard map is to create a dummy topic in the source map to which all these icons and tags have been added, then send (not copy and paste) this topic to a new map, which you can turn into the dashboard map.
(Edited)
Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Hi Alex,

Thanks in turn.

Your [temporary?] workaround for importing user-created tags and icon groups into dashboards is duly noted. Very good of you to share this while awaiting the possibility of an automated solution as MM dashboarding continues to evolve.

Best wishes,

David
Photo of Alex Gooding

Alex Gooding, Champion

  • 1025 Posts
  • 250 Reply Likes

Thanks David. There is an interesting variant on my workaround, which is to start off in the source map not with a dummy topic but with the dashboard map itself. An undocumented feature of MM is that you can create a roll-up map based on a floating topic within the same source map.

You can roll up as much of the source map as you like as topics linked to the floating topic, though bear in mind that tags and icons will be copied to the new map only if they appear on the topics involved in the rollups. Then send the floating topic to a new map, assigning it as the new central topic and ticking the boxes in the dialogue box to delete the original topics attached to the floating topic and to create links back to the source map.

You should end up with a dashboard map which incorporates the tag and icon groups, with just the floating topic remaining on the source map which is linked to the dashboard map. You can delete this or retain it as a handy button to take you to the dashboard map.
Photo of David Abrahams

David Abrahams

  • 57 Posts
  • 6 Reply Likes
Thanks for this additional twist.

At a simpler level I use rollups within a single map to replicate topics which are deployed in different parts of the same map and whose values need to remain constant in every instance (for example the standard cost of a common component used in various subassemblies).

At the risk of stating the obvious, the rollup feature means that you don't have to update each duplicate separately, even on the very same map. To the best of my knowledge, this is something which the current User Guide doesn't mention, referring only to rollups between maps. It's true that the Index then lists all the duplicate topics together, without identifying which of them is the 'master' for updates and edits. But since each rollup topic has a link to its master, the source topic is only ever one click away if you guess wrong and land on a duplicate.

Best wishes,

David