Ng-model and tm1-ui-rpt-view



The tm1-ui-rpt-view tag wont accept another ng-model as it’s argument for “tm1-cube”, it errors as being empty in the dev console.

This also applies to to “tm1-dimension” and “tm1-subset” in tm1-ui-rpt-row, tm1-ui-rpt-row-label & tm1-ui-rpt-column.

i.e. I can’t have dynamically changing cube value or dimensions as part of an active form call:


It’s the same issue that was found for tm1-ui-dbr.

Can this be included?

Any help greatly appreciated,



Hi Jack,

Not exactly sure what you mean, do you want a dynamic cube name? Like: tm1-cube="{{nameofcube}}"


Hey Tim,

So, cube name, dimension name, subset name in any of the active form tags based on the ng-model of another tag - in my case a DBR.

It’s the same issue I had with tm1-ui-dbr, which Paul updated in 1.0.5 or the release before.

If I set the cube, dim or subset values of any of the active form tags to the ng-model of another tag, it errors as being empty.



Hi Jack,

So you are using the result of a DBR to set a cube, dimension or subset in the active form? The active form checks for these attributes when it is created and they are static, i.e. if they are changed the active form isn’t updated.

What you could try is to include the tm1-ui-rpt-view inside an ng-if and only set the ng-if to true once you have value in your model. You can use $watch in your controller to capture when the model has been updated:

$ = {
    forecastCube: ""

$scope.$watch('page.forecastCube', function(newValue, oldValue){
  // Do stuff here  

Each time you set ng-if to true after it being false the contents of the element is recreated.


Hey Tim,

Thanks for the response.

Yeah, so basically the underlying TM1 model has a series of forecasting cubes that have the same number of dimensions, and only vary on a couple in terms of their name (but they are essentially the same thing) - the model has a forecast cube per region, basically, rather than one massive forecasting object.

When a user changes “entity”, the relevant forecasting cube changes, so the reference for the active form view, cube, some dims and some subsets change - so I was trying to assign these parameters to the results of ng-models from other tags (typically tm1-ui-dbr and tm1-ui-subnm).

I can do this in tm1-ui-dbr (i.e. make the cube parameter change dynamically based the value derived from another tag, i.e. tm1-cube="{{page.whatever}}".

I’ll have a look at setting something along the lines of what you kindly posted above, I was just wondering if this was expected behaviour, as tm1-ui-dbr also used to have this limitation until it was updated in the latest release?



@tganz can you have a look at this? By the sounds this could have implications for us with the C3 dimension maintenance wizards where we need to dynamically swap out the tm1-ui-rpt-row dimension.



Isn’t tm1-cube watched already, without having to write any additonal js, like tm1-suppress-zero, which does rebuild and active form based on a dynamic value?



Hi @jtuckerman,

The fix for the tm1-cube parameter so that it can be dynamic is in and will be part of the next build release.




Hi Scott,

I don’t think that should be an issue for us,

Jack is talking about dynamic Cube name, which is not the case for the wizards.


Hi Tomer,
no I think it might be. Or at least it is in the existing websheet interface. For example }APQ Dimension Attribute Definition or }APQ Security Effective Client Element Permissions the cube reference in the displayed data table is always to this cube but the row element reference is to }APQ Dimension Elements which is flat. In order to use the actual selected dimension (not a subset from the flat }APQ Dimension Elements dimension) we trick the active form by pulling one column from the }ElementAttributes cube which is hidden and this cube is referenced in the TM1RptView formula to enable the row dimension to also be dynamically swapped and be able to collapse & expand hierarchies etc. So the cube name reference for the active form is dynamic even though the cube reference to the rest of the data grid (which looks like it is part of the active form but isn’t) is static.

I’m not sure if we have the same flexibility in Canvas (but I hope we do). If we do and we manage the cube reference in the same way to manage zero suppression, etc. then we will have the same issue I think.


If you are (which I think you are doing) using tmi-ui-dbr within the active form directives, you will be fine.

I have already built grids using a combination of active form directives and the dbrs for my data - tm1-cube in tm1-ui-dbr currently supports dynamic values.

Regardless, Paul has suggested that the active form directives will work in the same way in a forthcoming release.