SACMRT_ASPECT_USER_EXT

@EndUserText.label: 'ACM RT: Aspect User Extensions'
@AccessControl.authorizationCheck: #NOT_ALLOWED
@AbapCatalog.entityBuffer.definitionAllowed: true

/*
  As this CDS entity is used in the generic aspects USER_ALIAS and USER_BUSINESS_PARTNER_NUMBER as data source, it needs to
  document how the retrieved data can be audited.
*/ 
@AccessControl.auditing.type: #CUSTOM
@AccessControl.auditing.specification: 'User Information System (Transaction SUIM) allows reconstruction of alias name and business partner assigned to a logon user'


//  ######                                          #    #                                    

//  #     # ######   ##   #####     #####  #   #    #   #  ###### #####  #    # ###### #      

//  #     # #       #  #  #    #    #    #  # #     #  #   #      #    # ##   # #      #      

//  ######  #####  #    # #    #    #####    #      ###    #####  #    # # #  # #####  #      

//  #   #   #      ###### #    #    #    #   #      #  #   #      #####  #  # # #      #      

//  #    #  #      #    # #    #    #    #   #      #   #  #      #   #  #   ## #      #      

//  #     # ###### #    # #####     #####    #      #    # ###### #    # #    # ###### ######

//

//  No changes without talking to the kernel developer! 


define view entity SACMRT_ASPECT_USER_EXT as 

  select
  
    /* 
      Using USR21 as the basis table.
      
      Previous versions of this view used USR02. This led to frequent invalidations of the table buffer for this view, because 
      USR02 is updated every time a user logs on to the system (USR02-LTIME: Last logon timestamp), and this, although not 
      relevant for this view, results in a complete invalidation of the table buffer (not only for the affected user). 
      
      Changed to USR21 in May 2022. It contains as well es USR02 a row for each user in the system, especially also 
      for users which also can have an alias or business partner. USR01 was not recommended because there might be 
      users with entry in USR02 but without USR01. For USR21 this issue should not exist.
    */
    from 
      usr21
    
    /* Alias from USREFUS */
    left outer to one join 
      usrefus
        on
          usrefus.bname = usr21.bname
          
    /*
      Since 2023, the business partner number was directly read from BUT000 using the join condition
      from I_BusinessUserBasic, with the introduction of the new SQL API in the kernel also 
      entities can be read, and they support view-on-view buffering, so I can now use the view directly.  
            
      There should be at most one hit here, so "left outer to one join" would be better. But the data model does not exclude multiple hits
      (that this does not occur is realized as ABAP code in user management and business partner), therefore I decide to 
      perform the "only one row" check in the ACM runtime in the kernel and react by dump.
    */                     
    left outer join
      I_BusinessUserBasic
        on
          I_BusinessUserBasic.UserID = usr21.bname
                
{

   key usr21.bname                                           as bname,
   key coalesce( I_BusinessUserBasic.BusinessPartner, ' ' )  as partner,       // ABAP table buffer does not allow NULL values in key fields

       usrefus.useralias                                     as useralias
   
}