Inconsistent security Canvas vs. TM1?


#1

Dear Canvas experts,

I’m currently testing a Canvas template with some non-ADMIN users and ran into the following issue:

Looking up an attribute value using <tm1-ui-dbra>, my test user cannot see the value in Canvas, while the value is retrieved fine for an ADMIN user.

OK, must be something related to security, so I checked the security. I logged on via Architect with my test user, but surprisingly I can easily navigate to the attributes and see the value. I confirmed this viewing the element attributes via context menu and also via }ElementAttributes_ cube. Additionally, I have sufficient permissions on the dimension itself and also on the }ElementAttributes dimension.

Now how should I proceed? Any idea to find out why Canvas will not show me the attribute value? I already tried <tm1-ui-dbr> to retrieve the value directly from the attribute cube, but the result is the same, which is not suprising.

If helpful: I have SSO configured with AuthenticationMode=5, but this was never a problem yet.

Thanks a lot,
Andreas


#2

Hi Andreas - are you sure about the same user being able to see the contents of the }ElementAttributes_dimension cube via other traditional TM1 UI?

If a user has read access to a dimension then there is no way to hide any attribute values (e.g. subset editor properties pane or DBRA). But special additional READ permission needs to be given to }ElementAttributes dimension & }ElementAttributes cube for the user to access }ElementAttributes cube values via cube viewer or DBRW formula to }ElementAttributes cube. … But assuming these steps are done then request via Canvas to the }ElementAttributes cube should work.


#3

Hi cw-ch,

I can confirm the user is the same and the user can see the values in the cube view via Architect. So I fully agree, it should work in Canvas. I now found something interesting:

I created a minimal example with some DBRA and static references to a specific element and attribute, just to exclude any stupid mistake here. And guess what, the test user can see the attribute value. I copied this piece of code to my Canvas page having the issue, and the value is only shown as “-”.

Here I observed that the same static piece of code works fine in the page having the issue, when placed OUTSIDE the active form. But why?!

This is my code for testing purposes, could not be more simple:
AttributeValue=<tm1-ui-dbra tm1-attribute="DateLoaded" tm1-element="Prognosis317" tm1-dimension="Event" tm1-instance="asdf" tm1-read-only="true"></tm1-ui-dbra>

See comparison: the highlighted value is from outside the active form. Below is just “-” inside the active form:

My only conclusion so far is that outside the ActiveForm tags, it works as expected, and inside, it doesn’t. I’m running Canvas 1.2.2. And again, this only applies for a non-ADMIN user, so should be related to authorizations somehow.

Any idea?


#4

As a workaround if instead of dbra you use dbr but to the }ElementAttributes cube then does it work?


#5

Hi @andreas.franke,

How does your DBRA code look like within the Active Form?

How do you access the elements from the rows in the active form?


Paul


#6

Guys, I finally solved it and happy to say it has nothing to do with authorizations. Of Course, the fact I could only observe this behaviour with a non-ADMIN user lead me in a wrong direction.

What happened?
I assume, I ran into kind of a timing issue where a dependent DBRA formula was evaluated before the referred element’s ng-model was ready. I think that for ADMIN users, the timing was not an issue, but probably some additional steps are performed for non-ADMIN users to check security etc etc, so that it takes a little longer.

The situation was that I retrieved an attribute value, stored it in a ng-model, and used this model to feed the tm1-element of another DBRA, which then did not get the result as obviously at the time of evaluation the ng-model was not yet populated.

Taking out my Statement from the active form and having it in the header first seem to make things working, but at the end only changed the timing a little bit, so this was also misleading.

At the end, I could not manage to force the right evaluation order of these two dependent DBRA. I now put a hidden SUBNM in between and feed its tm1-default-element with the first DBRA, and the second DBRA looks up the SUBNM’s ng-model now rather than the first DBRA’s ng-model directly. That way, Angular seems to do things in the right sequence.

Sorry for bothering you with that. I hope, someone running will make use of this post if running into a similar situation.

Andreas


#7

Hi @andreas.franke,

Great notes!

Just a few more things, when you mentioned that you have used two DBRA, the first one is to retrieve an element that is used on the second DBRA (i.e. a parent element hierarchy stored in one of the attribute)?

As in theory, with the DBRA, it should be able to resolve the values independently of each other.

Lastly, a possible alternative, if resolution sequence is needed, is by using ng-if like:

<tm1-ui-dbra ... ng-model="values.dbra1"></tm1-ui-dbra>
<tm1-ui-dbra ... ng-if="values.dbra1.length > 0" tm1-element="{{values.dbra1}}" ng-model="values.dbra2"></tm1-ui-dbra>

Above should force the second DBRA to only initialize when the first DBRA has been resolved .


Paul