Thanks, qt_ky! That got us pointed in the right direction. Here are the queries we're working with now. We were able to resolve the issue from the other thread about incorrect project roles being listed.
Query for users with given roles
Code: Select all
select U.principalId, R.roleId from U in ASCLModel::User, R in U->has_SystemRole where R.roleId in ('SuiteAdmin','SuiteUser','DataStageAdmin','DataStageUser')
Query for user project permissions
Code: Select all
select U.principalId, P.contextId, R.roleId from U in ASCLModel::User, RA in U->assignedBy_RoleAssignment, P in RA->has_RoleContext, R in RA->definedBy_SystemRole order by U.principalId,P.contextId,R.roleId
Query for groups with given roles
Code: Select all
select G.principalId, R.roleId from G in ASCLModel::UserGroup, R in G->has_SystemRole where R.roleId in ('SuiteAdmin','SuiteUser','DataStageAdmin','DataStageUser')
Query for group project permissions
Code: Select all
select G.principalId, P.contextId, R.roleId from G in ASCLModel::UserGroup, RA in G->assignedBy_RoleAssignment, P in RA->has_RoleContext, R in RA->definedBy_SystemRole order by G.principalId,P.contextId,R.roleId
These seem to be pseudo-queries that iterate the java object models. You can view the compiled class files from the <ISHOME>\ASBNode\lib\java\ASCLModel_api_gen_ecore.jar file to get an idea of the valid values for the select list and "joins". For example, the getGroupName and getGroupType methods from UserGroup.class translate over to
Code: Select all
select groupName, groupType from UserGroup
and the getHas_SystemRole method from the UserGroup parent Principal.class gives way to the "join"
The data appears to be persisted in the ASCLMODEL_* xmeta tables, so it could probably be queried directly through SQL.
I had opened a case with IBM support about this and they suggested the DirectoryCommand tool with the -list and -details options. It provides similar results and does not require a plaintext password on the command line.