Authorization Check on ACTVT only?

Hi Folks,
I need to create an authorization object. My doubt is that I need an authorization for releasing purposes, this means that I don't need a check on any table field.
So my question would be if its possible to create an authorization object using only the ACTVT and validate at the program like this:
AUTHORITY-CHECK OBJECT 'Z_OBJECT1'
         ID 'ACTVT' FIELD '45'.
I would like to know if this is a good practice, or should I follow another strategy to achieve this.
Thanks in advance.
Regards,
Gilberto Li

Hi,
yes, you can create an authorization object with just activity field. There has to be at least one field in the object. You can also select which activities are allowed for this object. Usually, you want to restrict activities to some selected organizational areas such as plant or company code. Hence you usually have some additional fields in authorization object. But if you think that just activity type is sufficient for your case then go ahead. Definitely, using custom authorization objects is much better than maintaining various custom tables with ACLs.
Cheers

Similar Messages

  • Authorization check

    Hi ,
    i new to authorization so i need help ,
    i go to transaction SU21 and i choose some object for example:
    Object R_CPM_BSC
    Text Authorization Object SEM: BSC Elements
    Class SEM Strategic Enterprise Management*
    Author STASTNY
    Field name Heading
    SEMSCARD Scorecard
    SEMOBJTYPE Scorecard Elements: Object Type
    SEMOBJKEY Scorecard Elements: Object Key
    ACTVT Activity
    And when i push on permitted activities i get:
    R_CPM_BSC Authorization Object SE
    ACTVT Activity
    activists
    01 Create or generate
    02 Change
    03 Display
    04 Print, edit messages
    1. i have always just permitted activities for ACTVT ?
    if i wont that user just have display Authorization how i have to write it like below?
    AUTHORITY-CHECK OBJECT R_CPM_BSC
    ID ACTVT FIELD '03'
    thats it i don't use the other fields?
    Regards

    Hi,
    In general different users will be given different authorizations based on their role in the orgn.
    We create ROLES and assign the Authorization and TCODES for that role, so only that user can have access to those T Codes.
    USe SUIM and SU21 T codes for this.
    Much of the data in an R/3 system has to be protected so that unauthorized users cannot access it. Therefore the appropriate authorization is required before a user can carry out certain actions in the system. When you log on to the R/3 system, the system checks in the user master record to see which transactions you are authorized to use. An authorization check is implemented for every sensitive transaction.
    If you wish to protect a transaction that you have programmed yourself, then you must implement an authorization check.
    This means you have to allocate an authorization object in the definition of the transaction.
    For example:
    program an AUTHORITY-CHECK.
    AUTHORITY-CHECK OBJECT <authorization object>
    ID <authority field 1> FIELD <field value 1>.
    ID <authority field 2> FIELD <field value 2>.
    ID <authority-field n> FIELD <field value n>.
    The OBJECT parameter specifies the authorization object.
    The ID parameter specifies an authorization field (in the authorization object).
    The FIELD parameter specifies a value for the authorization field.
    The authorization object and its fields have to be suitable for the transaction. In most cases you will be able to use the existing authorization objects to protect your data. But new developments may require that you define new authorization objects and fields.
    http://help.sap.com/saphelp_nw04s/helpdata/en/52/67167f439b11d1896f0000e8322d00/content.htm
    To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.
    Authorization : An authorization enables you to perform a particular activity in the SAP System, based on a set of authorization object field values.
    You program the authorization check using the ABAP statement AUTHORITY-CHECK.
    AUTHORITY-CHECK OBJECT 'S_TRVL_BKS'
    ID 'ACTVT' FIELD '02'
    ID 'CUSTTYPE' FIELD 'B'.
    IF SY-SUBRC 0.
    MESSAGE E...
    ENDIF.
    'S_TRVL_BKS' is a auth. object
    ID 'ACTVT' FIELD '02' in place 2 you can put 1,2, 3 for change create or display.
    The AUTHORITY-CHECK checks whether a user has the appropriate authorization to execute a particular activity.
    This Authorization concept is somewhat linked with BASIS people.
    As a developer you may not have access to access to SU21 Transaction where you have to define, authorizations, Objects and for nthat object you assign fields and values. Another Tcode is PFCG where you can assign these authrization objects and TCodes for a profile and that profile in turn attached to a particular user.
    Take the help of the basis Guy and create and use.
    Thanks
    Vikranth

  • Authorization Check in Business Transactions in CRM 2007

    Hi everybody, I have a problem whit the authorization check in CRM 2007.
    This link help me to follow the steps
    http://help.sap.com/saphelp_crm60/helpdata/en/e9/b29a39e7aee372e10000000a11
    I follow this steps:
    1.- Created a new single role on the PFCG
    2.- On the Menu tab add the transaction BSP_CRMD_BUS2000108 (Trax for LEADS)
    3.- On the authorization tab create a new profile and in the authorization data set the values for CRM_ORD_OP: PARTN_FCT ‘00000012’, PARTN_FCTT ‘*’, ACTVT ‚'02,03’
    4.- Generate the authorization.
    5.- Set my user "TESTUSER" on the user tab
    6.- Save the profile
    Then, I login to CRM whit TESTUSER and I see all the leads.  I miss something, what could be the problem ?
    Thanks for your help

    Hi Shaji, Pankaj and Jushan, thanks four your answers.
    I still have the same problem, I want to see only my leads that I´am the responsible, after I generated the authorization and assign the role to my user from tcode PFCG and SU01, I logout and login again and no changes, I still see all the leads.
    Another test I made, I changed the authorization data and set the values for CRM_ORD_OP: PARTN_FCT ‘’, PARTN_FCTT ‘0008’, ACTVT ‚'’   (person responsible)  and the results was the same, see all the leads.
    How works the User Comparisons and how can I check for errors in my pfcg role ?
    Thanks for your help.

  • Authorization checks and objects

    Do you have a tutorial for this topic for dummies? thanx in advance

    Hi
    In general different users will be given different authorizations based on their role in the orgn.
    We create ROLES and assign the Authorization and TCODES for that role, so only that user can have access to those T Codes.
    USe SUIM and SU21 T codes for this.
    Much of the data in an R/3 system has to be protected so that unauthorized users cannot access it. Therefore the appropriate authorization is required before a user can carry out certain actions in the system. When you log on to the R/3 system, the system checks in the user master record to see which transactions you are authorized to use. An authorization check is implemented for every sensitive transaction.
    If you wish to protect a transaction that you have programmed yourself, then you must implement an authorization check.
    This means you have to allocate an authorization object in the definition of the transaction.
    For example:
    program an AUTHORITY-CHECK.
    AUTHORITY-CHECK OBJECT <authorization object>
    ID <authority field 1> FIELD <field value 1>.
    ID <authority field 2> FIELD <field value 2>.
    ID <authority-field n> FIELD <field value n>.
    The OBJECT parameter specifies the authorization object.
    The ID parameter specifies an authorization field (in the authorization object).
    The FIELD parameter specifies a value for the authorization field.
    The authorization object and its fields have to be suitable for the transaction. In most cases you will be able to use the existing authorization objects to protect your data. But new developments may require that you define new authorization objects and fields.
    http://help.sap.com/saphelp_nw04s/helpdata/en/52/67167f439b11d1896f0000e8322d00/content.htm
    To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.
    Authorization : An authorization enables you to perform a particular activity in the SAP System, based on a set of authorization object field values.
    You program the authorization check using the ABAP statement AUTHORITY-CHECK.
    AUTHORITY-CHECK OBJECT 'S_TRVL_BKS'
    ID 'ACTVT' FIELD '02'
    ID 'CUSTTYPE' FIELD 'B'.
    IF SY-SUBRC <> 0.
    MESSAGE E...
    ENDIF.
    'S_TRVL_BKS' is a auth. object
    ID 'ACTVT' FIELD '02' in place 2 you can put 1,2, 3 for change create or display.
    The AUTHORITY-CHECK checks whether a user has the appropriate authorization to execute a particular activity.
    This Authorization concept is somewhat linked with BASIS people.
    As a developer you may not have access to access to SU21 Transaction where you have to define, authorizations, Objects and for nthat object you assign fields and values. Another Tcode is PFCG where you can assign these authrization objects and TCodes for a profile and that profile in turn attached to a particular user.
    Take the help of the basis Guy and create and use.
    Thanks
    Seshu

  • Authorization check by Cost centers

    Hello all,
    I developed a report in Report Painter and the requirement is that the users be able to run it only for their own CCtrs - challenge is that we are trying to not use variants, custom transactions and also modifying / checking authorization at at SU01 level.
    Is there any other way to do this and if yes can you pls provide some details.
    Thanks,
    Richa

    hi richa,
    Authorizations with Variables
    Definition
    Instead of using a single value or interval, you can also use variables in authorizations. The Customer Exit is called up for these variables while the authorization check is running. The call is carried out with I_STEP = 0. The intervals of characteristic values or hierarchies for which the user is authorized can be returned here. By doing this, the maintenance load for authorizations and profiles can be reduced significantly.
    Every cost center manager should only be allowed to evaluate data for his/her cost center. Within the SAP authorization standard, a role or a profile with the authorization for the InfoObject 0COSTCENTER equal to ‘XXXX’ (XXXX stands for the particular cost center) would have to be made for every cost center manager X. This then has to be entered in the user master record for the cost center manager.
    Using variables reduces the authorization maintenance workload with the InfoObject 0COSTCENTER equal to ‘$VARCOST’, as well as with the role or the profile, which is maintained for all cost center managers. The value of the variable ‘VARCOST’ is then set for runtime during the authorization check by the CUSTOMER-EXIT ‘RSR00001’.
    Maintaining the authorizations restricts the entries for the values to the length of the existing InfoObject. It is possible, however, to use both limits of the interval. In the example 0COSTCENTER with 4 spaces, the variable ‘VARCOST’ is, therefore, entered as ‘$VAR’ – ‘COST’.
    There is a buffer for these variables. If this buffer is switched on, the customer exit is only called up once for a variable with the authorization check. In doing so, you avoid calling up the customer exit for variables over and over, as well as decreasing performance. If you want to call up the customer exit each time, you have to deactivate this buffer in the Setting Up Reporting Authorizations. To do this, go to the main menu and choose Extras  ® Compatibility  ® Buffer for Variables (Customer-Exit)  ® Deactivate..
    You can also call up the customer exit for authorizations for hierarchies. There are two ways to do this:
           1.      Enter the variable in the authorization for characteristic 0TCTAUTHH. The customer exit is then called up while the authorization check is running. In the LOW fields of the return table E_T_RANGE, the system anticipates the technical name for the hierarchy authorization that you specified in the authorization maintenance (transaction RSSM).
    As a result, all parameters are available for such an authorization. Nevertheless, you must also create a new definition for each node.                                    
           2.      Where many authorizations differ from an authorization for a hierarchy only in respect to the nodes and not to the other authorizations, we suggest the following solution: Different users can be authorized for a specific hierarchy area (subtree). The highest node is different for each user.                                          
    Do this by creating an authorization for a hierarchy in the transaction RSSM and enter this in the authorization or role. Instead of specifying a particular node, you specify the variable in the authorization maintenance (transaction RSSM). The customer exit is then called up for the node while the authorization check is running. The return table E_T_RANGE must be filled according to the customer exit documentation (nodes in the LOW field, InfoObject of the node in the HIGH field
    Setting Up Reporting Authorizations
    Use
    Before you are able to set up reporting authorizations, you have to create authorization objects.
    As soon as an authorization object is saved, it can be checked when a query is run. The user may not have the appropriate authorizations if he or she has not yet been assigned this authorization object.
    Only when the user has been assigned the appropriate authorizations can he/she define and execute a query or navigate in an existing query.
    If in the query a characteristic value or a node is excluded, a complete authorization check “*” is required.
    Procedure
    Creating an authorization object
           1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose the path SAP Menu ® Business Explorer ® Authorizations ® Reporting Authorization Objects.
           2.      Choose Authorization Object ® Create. Give the authorization object a technical name and a regular name. Save your entries.
           3.      On the right-hand side of the screen, an overview of all the InfoObjects that are authorization-relevant is displayed.
    Only those characteristics that have been flagged as authorization-relevant previously in the InfoObject maintenance screen can be assigned as fields for an authorization object. See also: Creating InfoObjects: Characteristics
           4.      Assign the InfoObject fields to the authorization object:
    ¡        Select the characteristics for which you want an authorization check of the selection conditions to be carried out.
    ¡        Select the InfoObject key figure (1KYFNM) if you want to restrict the authorization to a single key figure.
    ¡        Select the InfoObject (0TCTAUTHH) if you want to check authorizations for a hierarchy.
    ¡        Include the authorization field activity (ACTVT) in the authorization object if you want to check authorizations for documents.
           5.      Save your entries.
           6.      Go back to the initial screen of the authorization maintenance.
           7.      Choose Check for InfoProviders ® Display to get a list of the InfoProviders that contain the InfoObjects that you selected and are therefore subject to an authorization check (where-used list). In the change mode you can exclude individual InfoProviders from the authorization check for this authorization object by removing the flag.
    Authorization object:           S_RSRSAREA
    Name:                   Sales area
    Fields:                         DIVISION, CUSTGROUP, 1KYFNM
    Creating authorizations
    Authorizations are created and maintained in the role maintenance screens.
           1.      Choose Authorizations ® Roles ® Change.
           2.      Specify the roles that you want to change and choose Change. This takes you to the role maintenance screen.
           3.      On the Authorizations tabstrip, choose the Expert mode for generating profiles option.
           4.      Choose the Enter Authorization Objects Manually option, and specify the objects that you require. Choose Enter. The authorization object is added to the role.
           5.      Choose Generate.
    For more information, see Changing and Assigning Roles.
    Result
    The user is now able to work with queries
    Authorizations to Work with a Query
    Use
    Authorizations to work with a query are first checked in the dialog box to open a query.
    Furthermore, when a query is opened, the authorizations for the individual objects are checked.
    See also: Authorization Check When Executing a Query..
    Structure
    Check in the Open Dialog Box:
    When you open a query, you will see four buttons in the dialog box. The History, Favorites and Roles buttons only display your own queries and those queries intended for you per role definition.
    The InfoAreas button enables you to look at all queries for which the user has display authorization. If this display authorization is not restricted to queries, the user will see all available queries in the system here. It is possible to hide the InfoAreas button if you do not want the user to see all queries in the system. The authorization object S_RS_FOLD with the field SUP_FOLDER can be used here. In order to hide the InfoArea button, set this field to X when authorizing, otherwise leave the field blank “ “ or set it to * (asterisk – all authorizations).. The button will be displayed if the authorization check fails.
    Authorizations by User
    It is also possible to make queries from particular users (= OWNER = query creator) available to other users (= USER) for display or processing. The authorization object S_RS_COMP1 with four fields (COMPID, COMPTYPE, OWNER, ACTVT) is used here.
    You can grant this authorization to a particular team or use the variable $USER to give all users the authorization for queries that they created themselves. $USER is replaced by the corresponding user name during the authorization check.
    See also the Example for Reporting Authorizations.
    Authorizations for the BEx Broadcaster
    Using the authorization object S_RS_BCS, you can determine which user is allowed to register broadcasting settings for execution and in which way.
    Note:
    ·        The only authorization necessary for the online execution of broadcasting settings is the authorization for the execution of the underlying reporting objects (for example, the Web template).
    ·        Every user that has authorization to create background jobs also has authorization for direct scheduling in the background.
    ·        If you need to work under the name of another user to execute broadcast settings (for example with user-specific precalculations), the authorization object S_BTCH_NAM for background scheduling is also required for the other user. For more information, see Authorizations for Background Processing and Definition of Users for Background Processing
    Authorizations for Selection Criteria
    Definition
    The selection criteria of a query determine which data can be displayed after you have entered it in a workbook.
    An authorization check for certain InfoObjects only takes place if an authorization object with this InfoObject was already created in the authorization object class Business Information Warehouse.
    As soon as an authorization object is created, only authorized users can select query data.
    Use
    To decide whether a user should be authorized to work with a query, you should check whether authorization has been given to him/her for all selection criteria.
    Essential to the authorization of selection criteria is the authorization object S_RS_ICUBE.
    Definitions of authorizations for working with certain InfoCubes must be transported separately.
    See: Transporting Additional Information
    In general, it is not sufficient to give authorizations for individual InfoObjects (characteristics and key figures), or to check them separately from one another. It more usual that specific authorizations should be given for combinations of characteristics and key figures.
    It is therefore feasible that a "Sales Manager" is allowed to view the respective total sales figures for all sales areas, but is only authorized to break down "his/her" area (0001) according to the individual sales personnel. In this case, the following authorizations, which are grouped together, would be created and assigned.
    Sales area = *
    Sales personnel = :
    Key figure = Sales figures
    (‘:’ represents the authorization to view the values aggregated with the characteristic.
    Sales area = 0001
    Sales personnel = *
    Key figure = Sales figures
    The user frequently uses these "multidimensional" authorities in companies that are regional as well as product-oriented (matrix organization). In this way, you could arrange for the person responsible for the combination of a certain division and a certain sales area to have the exact authorization for the output of the relevant values, without him/her necessarily also having access to the data for the whole division or the whole sales area.
    Authorizations for the Query Definition
    Authorizations can be granted for the following objects for the query definition in the Business Explorer:
    The entire query
    Structures
    Calculated key figures
    Restricted key figures
    Variables
    The activities for the query definition are specified in the authorization object S_RS_COMP (Business Explorer - components). The authorization object has the following fields: InfoArea, InfoCube, component type, component name and activity.
    The following values are possible for the component type:
    REP: Entire query
    STR: Structure
    CKF: Calculated key figure
    RKF: Restricted key figure
    VAR: Variables
    By specifying an InfoArea or an InfoCube, you can further restrict the component types. By specifying a component name, you can specify the authorization for individual components in more detail. Components that begin with 0 are delivered by SAP and cannot be changed. Components that are within the customer name range must begin with a letter of the alphabet.
    Valid activities are:
    01 (create)
    02 (change)
    03 (display)
    06 (delete)
    At the moment, activities 16 (Execute) and 22 (Save for Reuse) are not checked for the query definition.
    User A is allowed to create, change or delete queries beginning with A1 and A6 within InfoArea 0001 in InfoCube 0002. In addition, the user is allowed to change the calculated key figures and structures (templates) already defined in this InfoProvider.
    Related authorizations for user A:
    InfoArea: ‘0001’
    InfoProvider: ‘0002’
    Component type: ‘REP’
    Component Name: ‘A1’, ‘A6’
    Activity: ‘01’, ‘02’, ‘06’
    InfoArea: ‘*’
    InfoProvider: ‘0002*’
    Component type: ‘STR’, ‘CKF’
    Component name: ‘*’
    Activity: ‘02’
    Authorizations for Display Attributes
    Definition
    Authorization-relevant display attributes are hidden in the query if the user does not have sufficient authorization to view them.
    Use
    For characteristics:
    The user needs to have complete authorization (*) to see the display attribute in the query.
    For the characteristic 0EMPLOYEE, the 0EMPLSTATUS attribute is authorization-relevant. Only users with authorization "*" for 0EMPLSTATUS can display the attribute in the query.
    For key figures:
    Key figures cannot be marked as authorization-relevant. To use this function nonetheless for key figure attributes, the system checks against meta object 1KYFNM. For this, the user requires authorization for the field 1KYFNM in the authorization object.
    The key figure attribute 0ANSALARY is contained in the 0EMPLOYEE characteristic.
    If the user has the 1KYFNM field in his or her authorization object, and authorization "*", he or she can display all key figure attributes.
    If the user has the 1KYFNM field in the authorization object and the 0ANSALARY key figure as a value of the authorization, he or she can only see this key figure attribute. If the user is not supposed to see this attribute, do not give the authorization "*" but only assign the key figures for authorization that are to be displayed.
    Authorizations for Navigation Attributes
    Use
    During authorization checks for navigation attributes, it is always the characteristic that is being used as a navigation attribute that is checked.
    Integration
    If referencing characteristics are used as navigation attributes, authorization for the basic characteristic is checked. You should, however, change this logic so that the referencing characteristic is checked for instead. In the maintenance screen for reporting authorizations, choose the following path from the main menu Extras  ® Compatibility  ® Navigation Attributes ® Switch Off.
    This function exists for reasons of compatibility. The authorization logic of referencing characteristics worked differently with the beginning of Release BW 2.0. From BW 2.0, Support Package 20 and in all of the releases that follow, for referencing characteristics as well, the authorization for exactly this characteristic (and not the basic characteristic, as was the case previously) is checked.
    Example
    In the query, you use characteristic A with the navigation attributes A__B and A__R. Characteristic R references characteristic B. For these navigation attributes, authorization for the basic characteristic B is checked. If you switch off the compatibility for navigation attributes option, B is checked for A__B, and R is check for A__R.
    Maintaining Authorizations for Hierarchies
    Use
    Authorizations for hierarchies determine up to which subarea of a hierarchy a user may drilldown.
    Prerequisites
    Before you can set authorizations for hierarchies, you must first transfer and activate the InfoObject 0TCTAUTHH from the Business Content. Make sure that the indicator Relevant for Authorization is set. You must also create an authorization object for which you want to set the authorization.
    Authorization for a hierarchy on the Profit Center characteristic (0PROFIT_CTR):
    Define an authorization object with 0PROFIT_CTR and 0TCTAUTHH.
    Example: You define a hierarchy for the basic characteristic B. For characteristic B there is a referencing characteristic R. If you use this hierarchy for characteristic R in the query, authorization for the basic characteristic B is checked. However, you can change this logic so that characteristic R is checked for instead. In the maintenance screen for reporting authorizations, choose the following path from the main menu Extras ® Compatibility ® Ref. Characteristics with Hierarchy ® Switch Off.
    You need the characteristic 0TCTAUTHH to specify the hierarchy in the authorization. If you add this characteristic to an authorization object, you can specify authorizations for hierarchies for all InfoObjects in the authorization object.
    Procedure
           1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose SAP Menu ® Business Explorer ®Reporting Authorization Objects.
           2.      Choose Authorizations ® Authorization Definition for Hierarchies ® Change.
           3.      In the Definition, select the InfoObject, hierarchy and node.
    If there are several users who are authorized to work with just one part of a hierarchy (subtree) but the top node is different for each, you have the option of specifying a variable instead of a node.
    See also: Variable Types
    Instead of selecting a node, you can also set the Top of hierarchy indicator. This enables you to ensure that a user is authorized to use a hierarchy from the top node down to a determined level.
    You can select the top node here. However, if the hierarchy is being used in a query without a filter on this node, the user will not be able to execute the query.
    This is because the top-most visible node does not represent the actual top of the hierarchy. As, for example, there are other Remaining Leaves, there should always be exactly one internal node at the top of the hierarchy. Therefore, there is one internal node above the top-most visible node. If the hierarchy is used in a query without the top-most node being determined, it is compared with this unseen, internal node. So that the user has the correct authorizations, select the internal top of the hierarchy for this option.
           4.      Select the authorization type:
    ¡        0 for the node
    ¡        1 for a subtree below the node
    ¡        2 for a subtree below the node up to and including a level (absolute)
    You must define a level for this type. A typical example of an absolute level is data protection with regard to the degree of detail of the data (works council ruling: no reports at employee level only at more summarized levels).
    ¡        3 for the entire hierarchy
    ¡        4 for a subtree below the node up to and including a level (relative)
    You must specify a level that is defined relative to the node for this type. It makes sense to specify a relative distance if an employee may only expand the hierarchy to a certain depth below his or her initial node, but this node moves to another level when the hierarchy is restructured.
           5.      For types 2 and 4 you can specify, in Hierarchy Level, the level to which the user can expand the hierarchy.
    ¡        With authorization type 2 (up to and including a level, absolute) the level refers to the absolute number of the level in the hierarchy where the top-most node of the hierarchy is level 1.
    ¡        With authorization type 4 (up to and including a level, relative) the level number refers to the number of levels starting from the selected node itself which is level 1.
           6.      In the Validity Area you specify in exactly which ways a hierarchy authorization has to match a selected display hierarchy for it to be included in the authorization check.
    ¡        Type 0 (very high) : The name, version and key date of the hierarchy on which the hierarchy authorization is based have to agree with the selected display hierarchy.
    ¡        Type 1: The name and version of the hierarchy on which the hierarchy authorization is based have to agree with the selected display hierarchy.
    ¡        Type 2: The name of the hierarchy on which the hierarchy authorization is based has to agree with the display hierarchy.
    ¡        Type 3 (lowest) : None of the characteristics have to match.
    Note that in some circumstances, setting a check level that is too low may lead to more nodes being selected using hierarchy node variables that are filled from authorizations, than actually exist in the display hierarchy for the query. This can cause an error message.
    As a general rule, select the highest possible level for the check.
           7.      If you set the Node variable default value indicator, this definition of an authorization for a hierarchy is used as the default value for node variables.
    If more than several authorizations are assigned to a user for different subareas of the same hierarchy, one of these authorizations has to be defined as the default value. Only one node can be selected for a node variable on the variable screen of a query. So that this variable can be filled from the authorizations, the correct variable type has to be selected and an authorization has to be determined as the default value.
           8.      Specify a technical name for this definition. If you do not enter a value, a unique ID is set.
           9.      Now create an authorization for the new authorization object. To do this, enter the technical name of the definition as a characteristic value for the characteristic 0TCTAUTHH. Hierarchy authorizations and authorizations for characteristic values are added:
    ¡        Specify the value ‘ ‘ (a blank character) as a characteristic value if only hierarchy authorizations are to be in effect. If you specify more values these are authorized additionally.
    ¡        Specify the value “:” (a colon) when queries are also allowed without this characteristic.
    The value '’ (all characteristic values) is not supported for the characteristic 0TCTAUTHH. Nevertheless, if you specify the value ‚’ a ‚:’ is automatically generated instead because no other valid value is found.
    If you would like the user to be able to see all values and hierarchies for a characteristic, use the value '*' for this characteristic.
    If you use a drilldown hierarchy in the query, you restrict the highest node by a fixed node or a node variable.
    Definitions of authorizations for hierarchies must be transported separately. See: Transporting Additional Information
    Alternative Procedure:
    Manually Maintaining Reporting Authorizations
    Use
    You usually maintain authorizations in the role maintenance. However, in exceptional cases it could be more practical to create authorizations manually. This is the case if you have to assign every user his/her own role.
    Prerequisites
    Reporting authorization objects have been created.
    Procedure
    Assign Authorization Objects
           1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose SAP Menu ® Business Explorer ® Authorizations ® Reporting Authorization Objects.
           2.      Choose Authorizations ® Authorizations for Several Users. Enter an interval and choose Change.
           3.      Select a characteristic from the left side of the screen. You can then display master data as a list or as a hierarchy. The right side of the screen shows you a list of all the selected users with the authorization profiles and roles you assigned.
           4.      You can now use Drag&Drop to assign additional authorization objects to the user.
           5.      Choose Generate authorizations. The system creates the authorizations and assigns them to the users.
    Assigning Authorizations for Hierarchies
    You can also make authorizations for hierarchies in the same transaction.
           1.      Select a characteristic.
           2.      You can use the context menu on the authorization object to determine up to which hierarchy level the authorization should apply.
    You can currently select exactly 1 level for each hierarchy and user.
           3.      Choose Generate authorizations. The system creates the authorizations and assigns them to the user.
    Result
    The system has created individual authorization profiles.
    thanks
    karthik
    reward me ipoints if the above is usefull to you

  • Authorization checks in WDA View

    Hi All,
    I have a single WDA Compnent having one View. This View has some buttons that only certain users should be allowed to access. So I need to carry out authorization checks in Backend. Can someone please give me an example of how to proceed on such a scenario? Appreciate your help.
    Thks in advance, Liz

    Hi Liz..
    1) Create a field Zatt  " tcode:su20"and assign DATa Element (Type : WDYBOOLEAN).
    2) Create an ObjetClasse Zclass "tcode: su21"
    3) In this objectclass you create an authorization Object. Z2 that contain ACTVT and the Field Zatt .
    4) Now you can create one role "tcode : pfcg" with one authorization Z2 -> assign tha ACTVT : 03 and the Zatt to false.
    5) Assign this role to the user that "tcode: SU01".
    Finally in the WDY componant, you create a node with an attribute : Visibility type WDYBOOLEAN.
    you bind the attribute VISIBLE of boutons that you like to Hide .
    Finally -> In the method WDDOINIT of the main Insert this code :
    Authority-check Object 'ROLE_NAME'
        ID 'ACTVT' Field '03'
        ID 'Zatt' FIELD Visibility.
      IF sy-subrc EQ 0.
          Visibility = 'X'.
          lo_el_NADE_NAME->set_attribute(
          name =  `NODE_NAME`
          value = Visibility ).
      ENDIF.
    Hope It's Help
    Best Regards
    Edited by: Jcrios on Jun 4, 2010 4:21 PM

  • What are authorization checks? And where and what will you write?

    hai, plz anybody send me the answer?

    Hi
    In general different users will be given different authorizations based on their role in the orgn.
    We create ROLES and assign the Authorization and TCODES for that role, so only that user can have access to those T Codes.
    USe SUIM and SU21 T codes for this.
    Much of the data in an R/3 system has to be protected so that unauthorized users cannot access it. Therefore the appropriate authorization is required before a user can carry out certain actions in the system. When you log on to the R/3 system, the system checks in the user master record to see which transactions you are authorized to use. An authorization check is implemented for every sensitive transaction.
    If you wish to protect a transaction that you have programmed yourself, then you must implement an authorization check.
    This means you have to allocate an authorization object in the definition of the transaction.
    For example:
    program an AUTHORITY-CHECK.
    AUTHORITY-CHECK OBJECT <authorization object>
    ID <authority field 1> FIELD <field value 1>.
    ID <authority field 2> FIELD <field value 2>.
    ID <authority-field n> FIELD <field value n>.
    The OBJECT parameter specifies the authorization object.
    The ID parameter specifies an authorization field (in the authorization object).
    The FIELD parameter specifies a value for the authorization field.
    The authorization object and its fields have to be suitable for the transaction. In most cases you will be able to use the existing authorization objects to protect your data. But new developments may require that you define new authorization objects and fields.
    http://help.sap.com/saphelp_nw04s/helpdata/en/52/67167f439b11d1896f0000e8322d00/content.htm
    To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.
    Authorization : An authorization enables you to perform a particular activity in the SAP System, based on a set of authorization object field values.
    You program the authorization check using the ABAP statement AUTHORITY-CHECK.
    AUTHORITY-CHECK OBJECT 'S_TRVL_BKS'
    ID 'ACTVT' FIELD '02'
    ID 'CUSTTYPE' FIELD 'B'.
    IF SY-SUBRC <> 0.
    MESSAGE E...
    ENDIF.
    'S_TRVL_BKS' is a auth. object
    ID 'ACTVT' FIELD '02' in place 2 you can put 1,2, 3 for change create or display.
    The AUTHORITY-CHECK checks whether a user has the appropriate authorization to execute a particular activity.
    This Authorization concept is somewhat linked with BASIS people.
    As a developer you may not have access to access to SU21 Transaction where you have to define, authorizations, Objects and for nthat object you assign fields and values. Another Tcode is PFCG where you can assign these authrization objects and TCodes for a profile and that profile in turn attached to a particular user.
    Take the help of the basis Guy and create and use.
    As the name suggest it if for Authority check so that the person who is not having authorization for some data/transaction can be restricted from viewing it. It is very imortant for the security of data. Check below link for details on authorization.
    http://help.sap.com/saphelp_nw04/helpdata/en/9f/dbaccb35c111d1829f0000e829fbfe/content.htm

  • Authorization check For T code

    Hi everyone,
    Can anybody guide to set a  authorization check  for a particular Tcode.
    I have ztable where users are assigned particular numbers.
    I want the users who are assigned some numbers should be able to use this particular t code
    Thanks in advance

    hi
    chk this out
    AUTHORITY-CHECK
    Basic form
    AUTHORITY-CHECK OBJECT object
        ID name1  FIELD f1
        ID name2  FIELD f2
        ID name10 FIELD f10.
    Effect
    Explanation of IDs:
    object
    Field which contains the name of the object for which the authorization is to be checked.
    name1 ...
    Fields which contain the names of the
    name10
    authorization fields defined in the object.
    f1 ...
    Fields which contain the values for which the
    f10
    authorization is to be checked.
    AUTHORITY-CHECK checks for one object whether the user has an authorization that contains all values of f (see SAP authorization concept).
    You must specify all authorizations for an object and a also a value for each ID (or DUMMY).
    The system checks the values for the IDs by AND-ing them together, i.e. all values must be part of an authorization assigned to the user.
    If a user has several authorizations for an object, the values are OR-ed together. This means that if the CHECK finds all the specified values in one authorization, the user can proceed. Only if none of the authorizations for a user contains all the required values is the user rejected.
    If the return code value in SY-SUBRC is 0, the user has the required authorization and may continue.
    The return code value changes according to the different error scenarios. The return code values have the following meaning:
    4
    User has no authorization in the SAP System for such an action. If necessary, change the user master record.
    8
    Too many parameters (fields, values). Maximum allowed is 10.
    12
    Specified object not maintained in the user master record.
    16
    No profile entered in the user master record.
    24
    The field names of the check call do not match those of an authorization. Either the authorization or the call is incorrect.
    28
    Incorrect structure for user master record.
    32
    Incorrect structure for user master record.
    36
    Incorrect structure for user master record.
    If the return code value is 8 or 24, inform the person responsible for the program. If the return code value is 4, 12, 16 or 24, consult your system administrator if you think you should have the relevant authorization. In the case of errors 28 to 36, contact SAP because authorizations have probably been destroyed.
    Individual authorizations are assigned to users in their respective user profiles, i.e. they are grouped together in profiles which are stored in the user master record.
    Note
    Instead of ID name FIELD f, you can also write ID name DUMMY. This means that no check is performed for the field concerned.
    The check can only be performed on CHAR fields. All other field types result in 'unauthorized'.
    Example
    Check whether the user is authorized for a particular plant. In this case, the following authorization object applies:
    Table OBJ: Definition of authorization object
    M_EINF_WRK
       ACTVT
       WERKS
    Here, M_EINF_WRK is the object name, whilst ACTVT and WERKS are authorization fields. For example, a user with the authorizations
    M_EINF_WRK_BERECH1
       ACTVT 01-03
       WERKS 0001-0003 .
    can display and change plants within the Purchasing and Materials Management areas.
    Such a user would thus pass the checks
    AUTHORITY-CHECK OBJECT 'M_EINF_WRK'
        ID 'WERKS' FIELD '0002'
        ID 'ACTVT' FIELD '02'.
    AUTHORITY-CHECK OBJECT 'M_EINF_WRK'
        ID 'WERKS' DUMMY
        ID 'ACTVT' FIELD '01':
    but would fail the check
    AUTHORITY-CHECK OBJECT 'M_EINF_WRK'
        ID 'WERKS' FIELD '0005'
        ID 'ACTVT' FIELD '04'.
    To suppress unnecessary authorization checks or to carry out checks before the user has entered all the values, use DUMMY - as in this example. You can confirm the authorization later with another AUTHORITY-CHECK

  • Issues with Analysis Authorization checks in APO

    Hi Friends,
    I am facing an issue with Analysis authorization checks in APO.
    We have setup user access based on Management Entity (Analysis authorization - AGMMGTENT and 0TCAACTVT) and core APO authorizations (based on the work profile - e.g: Demand Planner).
    Scenario: Consider User A has access to India and Australia Management Entities with 0TCAACTVT - *
    This user also has display access to all management Entities (AGMMGTENT - * and 0TCAACTVT - 03). This scenario works very well in Quality where the RSECADMIN trace shows check on both Characteristics. However in Production the RSECADMIN trace shows up only against AGMMGTENT (*) and by default takes 0TCAACTVT as (*).
    In Quality the Characteristics that get checked are as below : and it works as expected. Display access for Management Entities that are supposed to be displayed only and change access to only the Management Entities that it should.
    However the Trace for Production shows the following : As a result it is allowing the user to change access to all management Entities. Which is not desirable..
    Resultant trace results are as below: This should not happen..
    I have compared all Analysis Authorizations and it is same across both Instances. The Demand planner access is consistent too..
    Will it be possible for you to advise on what could I be missing.

    Hi All,
    If it helps, in Quality: the Authorization checks are listed as: Subselection (Technical SUBNR) 1
    while in Production it checks Subselection (Technical SUBNR) 1 in one place, however where it fails - the check happens as Subselection (Technical SUBNR) 0.
    Is there a way we can change this to SUBNR 1. Is there any table entry that I can look at to check if the Authorization check is functioning incorrectly..
    Please advise.. Thanks..
    Regards,
    Prakash

  • ESS: Who's Who Authorization Checks

    Hi,
    I am testing the ESS iView (tcode PZ01) in the Portal and it seems to be restricting the search results by my authorizations.  I am not getting a full list of people in the system.  Anyone know how to turn-off this authorization check?
    I noticed this only happens when I changed the ESS Who's Who customizing in the IMG for PZ01.  If I uncheck the checkbox 'Output fields list', then it checks authorzations.  I'm thinking this has something to do with using the BAPI vs. using the query infoset, as the documentation states.
    Message was edited by:
            Kenneth Moore

    Old post but I have had a similar issue and it was caused by P_ORGIN
    Infortype 0105 subtype?????
    Seem if the subtype is restricted then they are not displayed if subtype populated in the HR record.

  • Authorization Check for Special Stock Indicator in IE02

    Dear Gurus,
    Would like to check with you if there is an authorization check for change in Special Stock Indicator in IE02-SerData Tab?
    For example, the User will only be allowed to change the Special Stock Indicator only to "E" - Sales Order.
    Would appreciate your help.
    Thanks.

    Hi,
    This cannot be done by using standard auth object. Standard SAP doesnt support control via this field.
    Take help of your ABAP team and create an customized authorization object "Z_OBJECT" with field SOBKZ and which check these field value in table EQBS. Assign this auth object to role and profile you want.
    Use the user exit IEQM0003 Additional checks before equipment update. Give a logic to check auth object when while using equipment change tcode.

  • Deactivate authorization checks in BSP or function modules?

    Hi all
    I have a BSP application that seems to use a standard function module that performs an unwanted authorization check on object M_MATE_VKO (Material check on sales organization)
    I know it is possible to globally deactivate authorization checks in certain SAP transactions (SU24)
    Does anyone know if there is a similar functionality for BSP applications or function modules? Any suggestions on how to deactivate such authorization checks in BSP applications?
    Regards
    Mike

    > I will also check with my developer if this function module has any return codes etc that can be useful for a custom authorization check. However, I thought these checks were all done within the function module and that it will only return a true/false authorization, sort of... and I am not sure it's a good idea to override all standard authorization checks in this function module
    Sometimes you can handle the messages, but your developer will be able to help you decide whether that is a good idea or not.
    Globally deactivating the object for the whole system is most likely not a good idea, as you seem not to want to grant it because you need it somewhere else...
    Deactivating all checks for the function module is probably not wise either, as I would think that it applies to the whole function group. Developers can do such things sometimes, but often it results in all end users being able to do the same.
    I know that proposal indicators can be set for function modules, but have not tried check indicators. Again, I suspect that it would apply to the whole function group.
    I would think that a carefull choice of function module and consulting with your functional guru about config which will not interfer with other requirements is the best route to take.
    I like threads like this. If I bump into a specific solution I will remember it. Try using the search here at SDN on the names of some of the FM's which you are considering - someone might already have solved it...
    Cheers,
    Julius

  • Authorization check failed

    hello experts!
    i created a program via smartforms but when my user try to generate a printed form an error message appear than FORM
    cannot be displayed. when i check Tcode: SU53 Authorization check failed.
    Object Class HR Human Resources
    Authorization Obj. P_ABAP  HR Reporting\
    Authorization Field COARS Degree of simplification for authorizaton check       1
    Authorization field REPID ABAP program name     ZHRPY00018C
    Please help on this one...
    How to fixed this
    Thank you

    hello...
    actually this report has 2 display a List display and via smartforms...
    we laready add this program  in her authorization profile... the only problem
    is when she try to generate the report via smartform she cannot produced the
    the output print docu. because an error appears that my FORM cannot be display.
    But when i check it in the development i can produced a test document.
    please help...

  • Structural authorization check in HR-ABAP

    Hello Friends,
    I am not able to get how to do the structural authorization check, my exact problem was : There is a report where it diplays all the qualifications of the employees and now I should restrict to only the employees who belongs to the organization unit depending upon the user who is running the report belongs to. It should check some more authorization profiles also.
    Regards,
    Yoganand.

    Hi Yoganand,
    if you use logical database PCH in your report, it should work by default.
    Manually search for RHSTRUAUTH in transaction SE37. There
    is a function modul which gives a list with the person the user has authorization.
    With this list you could compare the list with selected persons.
    hope this helps.
    Regards
    Bernd

  • LDB PNP authorization check at record level - rp_provide_from_last

    hi,
    i am using LDB PNP,
    I am using macro 'rp-provide-from-last' .
    I neeed to place a authorization check so that the user of the program should only be allowed to view records of the people which comes under the same personnel area as of the user of the program.
    Can you please guide me on how to implement this?
    thanks in advance,
    akash.

    Hi,
    (1)
    Actually, if you're wirting report with PNP LDB, you do NOT need to do this hard-coded auth checking at all. Because the LDB abap code behind PNP has already do this job for you.
    So all you need to do is to ask you HR consultant or Basis consultant to modify the authority config of certain ROLE with t-code PFCG, and then assign that ROLE to certain user with t-code SU01.
    ABAP code behind PNP will automatically verify the current user according to his ROLE setting.
    (2)
    In some case you do not work with LDB report, then you need to do the authority check by yourself. General function  AUTHORITY_CHECK is what you need.  AUTHORITY_CHECK do the authority check by means of Authority Object.Belows are authority objects used in HR module(you can also see in PFCG if technial name switched on):
    P_ORGIN    HR: Master Data
    PLOG       Personnel Planning
    P_PCLX     HR: Clusters
    P_TCODE    HR: Transaction codes
    Sample of checking personal area:
    CALL FUNCTION 'AUTHORITY_CHECK'
         EXPORTING
              FIELD1              = ' PERSA'
              OBJECT              = 'P_ORGIN'
              USER                = 'SAPSUPPORT1'
              VALUE1              = 'Z001'  
         EXCEPTIONS
              USER_DONT_EXIST     = 1
              USER_IS_AUTHORIZED  = 2
              USER_NOT_AUTHORIZED = 3
              USER_IS_LOCKED      = 4
              OTHERS              = 5.  
    IF SY-SUBRC NE 2.
    MESSAGE E001(01) RAISING AUTH_FAILED.
    ENDIF.
    Reward if helpful pls!

Maybe you are looking for