How to check if the user has only the display authority of a message

Question

hi,
How to check if the user has only the display authority of a message but does not have the change authority for a certain message?
Best regards,

Answer 1

hi blake
though i am an application consultant and for authorisation u need to have help of BASIS person if u r not the one but still i can guide u regarding the same,
Basically Authorization Management 
Use
You can use the following authorization objects to control the authorizations for maintaining business partner data:
•        Authorization objects for the Business Partner:
•             B_BUPA_GRP
•             B_BUPA_ATT
•             B_BUPA_FDG
•             B_BUPA_RLT•       
Authorization objects for relationships:
•             B_BUPR_BZT
•             B_BUPR_FDG
In addition, you can assign an authorization group to a business partner in the dialog. The authorization group controls which users may maintain data for this business partner.
You can also define authorizations for fields and field groups using the Business Data Toolset (BDT). Depending on the settings you have made, the system carries out the relevant authorization checks.
In the dialog in the SAP GUI, you can display an overview of the authorizations assigned to you by pressing the button Settings.
For more information on authorization management, see the Implementation Guide (IMG) of the Business Partner, as well as in the Developer’s Handbook for the BDT under  Authorizations.
IntegrationAuthorization management for the Business Partner forms part of the  SAP authorization concept.
Prerequisites
You have made the necessary settings in Customizing of the Business Partner under Basic Settings--> -Address Management.
Moving over
AS ABAP Authorization Concept 
The ABAP authorization concept protects transactions, programs, and services in SAP systems from unauthorized access. On the basis of the authorization concept, the administrator assigns authorizations to the users that determine which actions a user can execute in the SAP system, after he or she has logged on to the system and authenticated himself or herself.
To access business objects or execute SAP transactions, a user requires corresponding authorizations, as business objects or transactions are protected by authorization objects. The authorizations represent instances of generic authorization objects and are defined depending on the activity and responsibilities of the employee. The authorizations are combined in an authorization profile that is associated with a role. The user administrators then assign the corresponding roles using the user master record, so that the user can use the appropriate transactions for his or her tasks.
Authorization Checks 
To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.
The following actions are subject to authorization checks that are performed before the start of a program or table maintenance and which the SAP applications cannot avoid:
•        Starting SAP transactions (authorization object S_TCODE)
•        Starting reports (authorization object S_PROGRAM)
•        Calling RFC function modules (authorization object S_RFC)
•        Table maintenance with generic tools (S_TABU_DIS)
Checking at Program Level with AUTHORITY-CHECK
Applications use the ABAP statement AUTHORITY-CHECK, which is inserted in the source code of the program, to check whether users have the appropriate authorization and whether these authorizations are suitably defined; that is, whether the user administrator has assigned the values required for the fields by the programmer. In this way, you can also protect transactions that are called indirectly by other programs.
AUTHORITY-CHECK searches profiles specified in the user master record to see whether the user has authorization for the authorization object specified in the AUTHORITY-CHECK. If one of the authorizations found matches the required values, the check is successful.
Starting SAP Transactions
When a user starts a transaction, the system performs the following checks:
•        The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.
•        The system then checks whether the user has authorization to start the transaction.
The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.
•             The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.
•             If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).
If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).
•        The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.
The check is not performed in the following cases:
You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.
This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.
•             You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25.
•             So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to “Y” (using transaction RZ10).
All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message.
Starting Report Classes
You can perform additional authorization checks by assigning reports to authorization classes (using report RSCSAUTH). You can, for example, assign all PA* reports to an authorization class for PA (such as PAxxx). If a user wants to start a PA report, he or she requires the appropriate authorization to execute reports in this class.
We do not deliver any predefined report classes. You must decide yourself which reports you want to protect in this way. You can also enter the authorization classes for reports with the maintenance functions for report trees. This method provides a hierarchical approach for assigning authorizations for reports. You can, for example, assign an authorization class to a report node, meaning that all reports at this node automatically belong to this class. This means that you have a more transparent overview of the authorization classes to which the various reports are transported.
You must consider the following:
•     •         After you have assigned reports to authorization classes or have changed assignments, you may have to adjust objects in your authorization concept (such as roles (activity groups), profiles, or user master records).
•     •         There are certain system reports that you cannot assign to any authorization class. These include:
•     •         RSRZLLG0
•     •         STARTMEN (as of SAP R/3 4.0)
•     •         Reports that are called using SUBMIT in a customer exit at logon (such as SUSR0001, ZXUSRU01).
•     •         Authorization assignments for reports are overwritten during an upgrade. After an upgrade, you must therefore restore your customer-specific report authorizations.
Calling RFC Function Modules
When RFC function modules are called by an RFC client program or another system, an authorization check is performed for the authorization object S_RFC in the called system. This check uses the name of the function group to which the function module belongs. You can deactivate this check with parameter auth/rfc_authority_check.
Checking Assignment of Authorization Groups to Tables
You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.
You can assign a table to authorization group Z000. (Use transaction SM30 for table TDDAT) A user that wants to access this table must have authorization object S_TABU_DIS in his or her profile with the value Z000 in the field DICBERCLS (authorization group for ABAP Dictionary objects).
please See also:
•        SAP Notes 7642, 20534, 23342, 33154, and 67766
guess this info will help you,there is one graphic which actually explain the hierarchy of authorisation,i will find some time out to let u know more info about the authorisation
but if u sit with ur BASIS guy then u can learn lot of things in PFCG
i guess u r a basis guy,then its not a problem
best regards
ashish