Is it possible to use the System dimension #_USER_ in a cube

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Is it possible to use the System dimension #_USER_ in a cube

      Hi there,

      I was wondering whether it is possible to use the System User-Dimension in a "normal" cube.

      Here is the reason for the request:
      I want to make the user access rights administration for one database easy for administration by power-users
      Therefore, I intended to make a cube with the data dimension and the user dimension, basically as a matrix to fill it with 1 and 0, when the access should be granted or denied.

      I know that it is possible to do this via the normal user administration in the system cubes. But the power-users do not have access to this and should still be able to grant or deny access for the people entering the values.

      So far I did not find an option. I also thought I just make an empty user dimension, create a cube and then draft a rule where the source is the #_USER_ dimension. But that is not possible either. At least I did not find a way, how to access the System db.

      Thanks a lot in advance.

    • Thanks,

      When I set up the Connection to the system, I could extract the Dimension #_USER.
      Does anyone know where the information is stored, that is visible in the System Manager about the users, e.g. name?
      When I checked to get attributes as well, it ran into an error.

      The usernames are at times hard to decipher to whom they belong, therefore it would be helpful to get the full name.
    • Thanks for the pointers,

      I had to do it without the system data though, because I would somehow have to get only the Users from a certain group and then the full name.
      Since this information is not stored in one dimension but in the case of the name even in a cube itself, I can not figure out how to create a "matrix" cube with that combined System information and a dimension from a different database.

      It seems that there is no other option then creating and maintaining a seperate dimension for this user group within the database. It is certainly double effort to maintain, but at least it works then.