Correct. But you can always create a new tab with the desired settings, delete the old, and rename it.

Can you duplicate a tab in that way? If so it would be fine... but to rebuild 20-30 tabs takes a lot of time (and its easy to introduce errors on aggregations etc.)

I don't see how aggregations are affected. For each simple tab "X", you open it then create a new advanced tab "X2" without capturing variable state. Then, delete the old tabs and rename the new.

Advanced tabs are quite complicated to understand so are only useful to our most advanced users. This, and the complexity of developing support for converting simple tabs to/from advanced tabs, means we can't promise this helper feature in the near future.

Steve

Fair enough - makes sense.

The challenge I have with aggregations is limited to the 'build' phase of any model... an example:

1. I have a file with 30 fields sourced from raw data sources
2. I add 10 'obvious' (an the start of the engagement) formulae to the file - I now have 40 fields
3. I add 10 tabs, each of which has 2-3 views... some of these views require aggregation (by different fields), so I set these up as I go... and in each case I set the correct aggregation type for each field (I used to do this only for the fields used in the view, but have since learned that I should do this for every field, in case I want to switch measure/split etc. at a later point)
4. In working with the client I am asked to create additional formulae to suit the problem at hand. I do this inside DataExplorer (rather than DataManager) during workshops etc. (when I'm being disciplined, and making time for myself, I will go back and cut/paste/test these from DataExplorer back into DataManager)...

... but these formulae now appear in every aggregation, in every view that uses aggregations, and I need to go back and check/test each one to ensure that the aggregation selected (sum/singleton) makes sense.

When it comes to creating new tabs, as you suggest, I have the same issue to deal with - ensuring that aggregations are correct and that all view settings are as they should be. This is an involved process, and the 'edit advanced' would result in considerably less effort when wanting to refactor a complex model... but if there is little/no demand then I understand your appetite to address it.

Opening tab X, creating a new advanced no-vars tab X2 from current state, deleting X, and renaming X2 to X, is exactly the same as hypothetically editing X and removing variables from it. There is no impact on setting in views, such as aggregation.

OK - thanks. Apologies, I didn't realise I could create from current state but amend advanced settings at the same time... this approach is 99.9% as good as editing advanced properties, so I will be using it immediately. Thanks.