No. There is a chrome plugin that works with version 6.3. That can be found here: https://chrome.google.com/webstore/detail/release-automation-permis/bojghbfgnapobcdoagkokikjhidjhemk
Before installing the extension you can see what requirements it has for setting it up.
In order for a user to be able to execute releases against an environment they one of the following must be true:
- The user must be a superuser
- A non-superuser must be given explicit permissions in the form of:
- At the application level: Application Owner; or
- At the application level: Execute Releases In All Environments with either "Environment Admin" or "Release Designer" privilege at the environment level; or
- At the application level: Nothing (except Can view application) with either "Environment Admin" or "Release Designer" AND "Can Execute All Releases" at the environment level.
The chrome extension provides insight (per application) on the privileges each user has.
Also, there is an SQL query that you could attempt to run. It is not anything officially certified but unofficially the following query should also provide the information you are looking for (limited testing done against v6.4):
asid.SID as USERNAME,
apps.APP_NAME as APP_NAME,
ae.MASK as MASK,
en.NAME as ENVIRONMENT_NAME,
appNameForEnv.APP_NAME as APPLICATION_NAME_FOR_ENV,
ug.name as LDAP_GROUP_NAME
FROM acl_sid asid
INNER JOIN acl_entry ae
LEFT OUTER JOIN acl_object_identity aod
LEFT OUTER JOIN applications apps
LEFT OUTER JOIN environments en
LEFT JOIN applications appNameForEnv
LEFT OUTER JOIN users u
LEFT OUTER JOIN user_groups ug
where asid.sid != 'superuser'
AND ae.mask='16' /*app owner privilege if app_name is populated. otherwise, environment admin if environment name is populated*/
or ae.mask='512' /*execute all releases in all environments if app_name is populated. otherwise, execute all releases for a specific environment if the environment_name is populated*/
or ae.mask='1024' /*release designer at envirtonment level*/;
The superuser username has an entry for each application/environment. That is why it is filtered via the query.
Users assigned the superuser role will not be returned in the output (maybe unless they specifically created an application). Users assigned the superuser role seem to be tracked via the AUTHORITIES table. This can be seen by running: select username from authorities where authority = 'ROLE_SUPERUSER'
This query was tested against an Oracle database. It might not work as advertised against MSSQL. Specifically there might be problems with the way it looks for user<->user_group information.
The NOT_IMPORTED_LDAP and LDAP_GROUP_NAME fields are provided in case the user retrieved its permissions from an imported LDAP group. Value of 0 for NOT_IMPORTED_LDAP means that the user was not imported. For LDAP users that get their permissions from an a group that was imported from LDAP, it will only make this information available if the user has logged into CA Release Automation since CA Release Automation doesn't keep track of what ldap groups an ldap user is a part of.