Apliqo UX Subset Editor Uses Attribute Cubes instead of Set Expressions

Apliqo UX
#1

We were troubleshooting a users dashboard this week where 1 dimension in the dashboard filters showed a yellow error symbol

image

Digging into the console we found that the MDX statement was returning a 400 error

{"error":{"code":"65","message":"ObjectSecurityNoReadRights"}}

Tracing through the TM1 Logs we found that the MDX was being used in a query against the }Element Attributes cube, which the user was not permitted to access.

SELECT {HEAD({TM1SUBSETALL([Financials_m].[Financials_m])}, 100000)} ON COLUMNS, {[}ElementAttributes_Financials_m].[Format]} ON ROWS FROM [}ElementAttributes_AWS Financials_m]

Why does UX reference the attributes cube rather than using a MDX Set Expression? Set Expressions would still enforce Dimension and Element security, but would not require full read access to the attributes cube.

Thanks

#2

@ishapiro can you please take a look?

#3

@cw-ch thanks. Let me know what you find. M

#4

this is natively how we built our Subnm directive ,
to relay on the element attribute cube, to fetch the attribute values.
is there a reason the user should not have access to this cube ?

#5

Yes, there are quite a few reasons.

One of which is when all dimension attributes are restricted. We see this in our workforce planning models mostly. The dimension is something like employee number or other identifier. The attributes contain all the details about that employee. For most users, they have no access to read attributes on that dimension, that is handled via cube security. Since they can’t read that cube, UX subset editor breaks.

Aside from the above, what happens when a dimension does not have an attribute cube?

#6

when the dimension does not have an attribute cube , we know there are no attributes at all for that dimension , so we know we dont need to query it at all.

Regarding your use case, I guess those users still need to to have access on at least 1 attribute on that dimension ?
if thats the case case you can give them read access to the element attribute cube,
and use dimension elements security on the attribute dimension.
so once we query the element attributes cube, we would only get the attributes they have access to.

would that work ?

#7

Also I think part of the answer is a little bit lost in history. When the directive was originally develloped TM1’s rest API didn’t support MDX set expressions so we had to query the attribute cubes. Although the rest API now does support MDX set expressions the directive has never been refactored to take advantage of this.

We have a recommendation to grant read access to the }ElementAttributes_ cube and dimension for any dimension which a group has read access to. From a security perspective on sensitive dimensions there shouldn’t be any issue with this since the restriction would still be handled by element security on the }ElementAttributes_ dimension in the same way as you describe it. There is a full technote in the KB on this topic. (some of the technote may now be a little out of date but that’s always the way with documentation).

#8

I figured there was a story behind it. Element security is an option, but it just complicates the security model more. Longer term I think set expressions would be more performant, but i understand that its probably low on the list since this is not really broken. Thanks for digging into this though.