Imagine you have written a nice CDS view, e.g. as follows:
@AbapCatalog.sqlViewName: 'Z_T100_SABDEMOS'
define view z_t100_sabapdemos
as select from t100
{ * } where arbgb = 'SABAPDEMOS'
It should select all messages for a distinct message class SABAPDEMOS from database table t100. And of course it does that, as the following code snippet proves:
SELECT *
FROM z_t100_sabapdemos
INTO TABLE @DATA(result).
cl_demo_output=>display( result ).
Now your're happy and ship your view, but ....
... someday you get an error message from a target system that users do not see all languages any more:
... and some users do not see anything at all (sy-subrc = 4).
You logon to the system and examine the database access with SQL Trace (ST05) and find funny things:
"DCL restrictions" what's that now???
You look at the properties of your view in that system and find in the Problems tab:
Uh-huh.
- You're view implicitly uses the default annotation @AccessControl.authorizationCheck: #CHECK.
Documentation says "If Open SQL is used to access the view, an access control is carried out implicitly if a CDS role is assigned to the view." - And someone has created a CDS role in a DCL source code for your view!
You find it in ADT:
@MappingRole: true
define role role_name {
grant select on z_t100_sabapdemos
where ( arbgb ) = aspect pfcg_auth ( s_develop, objname,
objtype = 'MSAG',
actvt = '03' )
and sprsl= 'E' ; }
What does that harmless looking code snippet do?
A CDS role adds an additional selection condition, a so called access condition, to a CDS view! If you access a CDS view that is mentioned in a role, Open SQL from ABAP 7.50 (and SADL Queries from ABAP 7.40, SP10) implicitly consider the access conditions defined in each role.
In our case:
- A literal condition sprsl='E' restricts access to English only.
- A so called PFCG condition aspect pfcg_auth ( s_develop ... ) connects the CDS role to a classical authorization object s_develop and from that the CDS access control runtime generates an access condition that evaluates the authorizations of the current user for that object. Here, a predefined aspectpfcg_auth connects the authorization field objname to the view field arbgb. Additionaly, the user's authorization is checked if it complies with fixed values for authorization fields objtype and actvt.
Neat!
If you write a view, you must be aware that this can happen. If you don't want any access restriction, you must decorate your view with the annotation AccessControl.authorizationCheck: #NOT_ALLOWED. Then and only then CDS roles are ignored.
But of course, CDS access control becomes part of your data modeling efforts from ABAP 7.50 on ...
A first documentation is available, an improved one will follow soon.
PS: The CDS roles supported by ABAP CDS up to now are implicitly assigned to each user, so to say. User specific CDS roles are principally possible but not supported yet (those would involve selfdefined aspects). Instead, PFCG conditions offer a new implicit access to classical authorizations.
_