Disable authorization check RH_STRUC_GET

hi,
is there a possibility to use FM
RH_STRUC_GET and to disable authorization check similar to 'HR_READ_INFOTYPE_AUTHC_DISABLE' for fm HR_READ_INFOTYPE?
thanks for help

stupid question - solved by myself.

Similar Messages

Disabling authorizations checks for transactions SU53 and/or SU56.

Greetings.
I seem to remember reading that there was either a system profile parameter or a table entry that can be used to disable all authorizations checks for transactions SU53 and/or SU56.
Any truth in this or is my mind playing tricks on me?

Hi,
I guess theres is profile param auth/tcodes_not_checked(I guess thats right), this will exclude SU53/SU56 from checks on transaction code.
This can be done using RZ10 and need to restart the system.
Rakesh

ABAP: Modify PA infotype without authorization check

Hello everyone,
Short version:
I know two FM that can modify PA infotype data: HR_MAINTAIN_MASTERDATA and HR_INFOTYPE_OPERATION. However, neither of those includes a parameter that allows using them without them automatically checking authorizations (like you can do with, say, FM RH_INSERT_INFTY which has parameter AUTHY to disable authorization checks but only works with OM infotypes, but not PA infotypes).
Does anybody know a solution?
Long version:
We want the travel department to be able to maintain infotype 17, and only infotype 17. In fact, there are only two fields there that need to be maintained in our company. That department should not have access to any other infotypes, and we are not going to give them PA30. On the other hand, they shall be able to do so for any employee, no matter from which personnel area, subarea, and organizational unit.
So I have created a small program with a mask specifically tailored to their needs. But we do not want to give them any PA authorizations. Giving them P_ORGIN to infotype 17 might not be a big deal, but then we would also need to give them structural authorization to all companies (= org units and personnel areas). Unlimited structural authorization is a big deal, and I would rather avoid granting that to someone who is not supposed to be doing anything but this tiny bit in HR. The only authorization that I would like to see in place is transaction authorization for my program. Anyone who has that should be allowed to maintain these IT 17 fields for any employee, but nothing else.
The problem is that upon writing the data, FM HR_INFOTYPE_OPERATION auto-checks the authorization required for maintaining the infotype, including structural authorization, and so does FM HR_MAINTAIN_MASTERDATA, as far as I understand. Is there an alternative I could go for?

ECM stands for Employee Compensation management and is one of the SAP HR module.
But I doubt you can use ECM specific function module to modify/insert infotype 17 values as below are the main infotypes for ECM module.
Employee Infotype
Description
0758
Compensation Program
0759
Compensation Process
0760
Compensation Eligibility Override
0761
LTI Granting
0762
LTI Exercising
0763
LTI Participant Data

Kanban authorization checks (SU24, PK13N, PK*)

Hi,
Does anyone know why the Kanban transactions (PK*) have mostly disabled authorization check indicators in SU24?
In PK13N, for example, there is functionality to do a goods receipt (MIGO GR) and also functionality to create POs (and maybe more that I have not looked into yet).
However, the related auth objects in SU24 are not enabled (check indicator = do not check). This seems strange for these authorization objects.
Especially in light of SoD. Users could create POs or do Goods Receipt via PK13 without proper auth check and these 2 functions conflict already (using default GRC ruleset).
But that's beside the point. The question is: Is there a good reason why these are disabled and how is this NOT a secuty risk?
Now, there is one object that is enabled: C_KANBAN
But, I feel that this is insufficient to really secure the goods receipt action and the PO creation action.
For reference, a list of disabled auth objects:
C_STUE_WRK CS BOM Plant (Plant Assignments)
C_TCLS_MNT Authorization for Characteristics of Org. Area
F_BKPF_KOA Accounting Document: Authorization for Account Types
F_FICA_CTR Funds Management Funds Center
F_FICA_FTR Funds Management FM Account Assignment
F_FICB_FKR Cash Budget Management/Funds Management FM Area
F_FICB_FPS Cash Budget Management/Funds Management Commitment Item
F_LFA1_APP Vendor: Application Authorization
F_SKA1_BUK G/L Account: Authorization for Company Codes
L_BWLVS Movement Type in the Warehouse Management System
L_LGNUM Warehouse Number / Storage Type
M_BANF_BSA Document Type in Purchase Requisition
M_BANF_EKG Purchasing Group in Purchase Requisition
M_BANF_EKO Purchasing Organization in Purchase Requisition
M_BANF_WRK Plant in Purchase Requisition
M_BEST_BSA Document Type in Purchase Order
M_BEST_EKG Purchasing Group in Purchase Order
M_BEST_EKO Purchasing Organization in Purchase Order
M_BEST_WRK Plant in Purchase Order
M_LPET_EKO Purchasing Org. in Scheduling Agreement Delivery Schedule
M_MRES_BWA Reservations: Movement Type
M_MRES_WWA Reservations: Plant
M_MSEG_BWA Goods Movements: Movement Type
M_MSEG_BWE Goods Receipt for Purchase Order: Movement Type
M_MSEG_BWF Goods Receipt for Production Order: Movement Type
M_MSEG_LGO Goods Movements: Storage Location
M_MSEG_WMB Material Documents: Plant
M_MSEG_WWA Goods Movements: Plant
M_MSEG_WWE Goods Receipt for Purchase Order: Plant
M_MSEG_WWF Goods Receipt for Production Order: Plant
M_RAHM_BSA Document Type in Outline Agreement
M_RAHM_EKG Purchasing Group in Outline Agreement
M_RAHM_EKO Purchasing Organization in Outline Agreement

Hi Steven
Normally, when I submit OSS messages about security gaps the response is "working as designed", so I thought I'd try SCN first... perhaps it REALLY IS working as designed and there is a good reason why no auth checks should happen in this case.
Unfortunately this is all too common. However, I have found a lot of the times it is a Level 1 Support person in SMP advising you of this. With perseverance and escalation to a the next level the chance of a fix is greater (still not a guarantee)
It's a pity if working as per design they could explain why.
MIGO can be used in display mode only. If PK13 and PK13N are meant to be display transaction and the SU24 allows you to perform change (i.e. none of the underlying auths are checked for change) then I would refuse to close the customer incident until SAP responds further. At the end of the day, if a display transaction allows modification then it isn't a display transaction
I get the impression SU24 and some other security (e.g. authority check on '' instead of dummy) has been allowed to exist as customers give up and change the values themselves instead of getting SAP to fix their solution.
You could also look at SE97 if call transaction can be switched to yes so users cannot jump from PK13N to MIGO (assuming the code was a CALL TRANSACTION)
Regards
Colleen
P.s. - understand the comment with stale thread but take note of timezone and if you raise it on a Friday people may not see it until the following week. Although you did consider this, a lot of people on SCN put urgent in their question and then within the same day respond to their thread to "bump it" on the list

Authorization Check on Radio Button

Hi,
I have a custom report which has a radio button. Can I provide the authorization on this radio button, meaning only selected no. of users can run this report with radio button checked. I know it's possible through maintaining a list of users in custom table, But I want to check if we can do it using authorization object/group etc...

Birendra, you're absolutely correct that we need to consider future maintenance efforts. But this is exactly a weak side of the parameter approach that you've suggested. The jet analogy is impressive, but way out of proportion in this case.
Using authority check command in ABAP code and modifying screen elements is not hard-coding. The parameter approach also requires writing some code, so it has no advantage here.
Also it requires someone (a Basis admin?) to update the user profile and a table entry that you've mentioned. To use the standard authorizations, only one authorization object will need to be created (although it may even be possible to use another, existing object if it's the same authorization level). It won't take more space or more time to create than an SM30 entry. Updating the roles might be more of a hassle than updating the user parameter, but the difference can hardly be considered significant and it's a one-time thing anyway.
It is a matter of preference whether to hide a control, disable it or display a message. (By the way, in many standard transactions you'll find that controls or menu options are hidden/disabled based on authorization, so it is nothing exotic.) But I stand by my suggestion of using standard authorization check functionality specifically because it makes the future maintenance easier.
1) Basis admins most likely already maintain some document regarding the role assignment. It might be actually easier to them to maintain the roles than to keep track of the additional profile parameter and remember it in future.
2) Imagine years from now you're gone and all the new people are maintaining the system. The user gets a 'no authorization' message and, naturally, contacts a system admin. Again, naturally, admin will check security trace. Now guess what - your parameter thingy cannot be tracked anywhere. No one knows about it and it will take an ABAPer to figure this out.
With standard approach it will only take a second to run SU53 and a few minutes to resolve an issue by a Basis admin. Additionally, authorization objects have 'where used' button, so it would be easy to check if and where the object is used (e.g. if the report has been changed/deleted it will be easy to spot the 'orphaned' object). With the profile parameter sooner or later someone will have to wonder what the heck it is for and might accidentally delete it. By the way, sometimes users actually have access to their own parameters, so it's not a very secure option either.
I understand you mean well, but, unfortunately, in my work quite frequently I have to deal with some things that were developed by well-meaining consultants who overlooked some long-term effects of their approach.

Authorization checking in BAPI

Hi,
I put in authorization checking for the 'Material group 1' field of a SD document. With this, only authorized users are allowed to change this field while other users without the authorization will not be allowed to change it. When i tested the authorization in VA02, it works fine. I was able to change it as i has been assigned with the required role/profile. On ther other hand, the other user without the role/profile was not able to change the field using VA02. I did another test using a Z program that calls 'BAPI_SALESORDER_CHANGE'. The Z program will change the 'Material group 1' field using 'BAPI_SALESORDER_CHANGE'. My initial thought was me with the required role/profile when running the Z program, will be able to change the field while the other user without the required role/profile will not be able to change it when running the Z program. However, the result shows that both users (with/without the role/profile) was also able to change the field using the Z program. Is there anyway to control the BAPI so that it works the same as in VA02? Thanks much for your advice.

In your coding change
IF sy-tcode = 'VA02'.
to
IF T180-TRTYP = 'V'.
Then your coding will also work with BAPI. Try putting a break point before the If clause and execute the BAPI, you can see it yourself.
SAP will set T180-TRTYP = 'H' for create, = 'V' for change and = 'A' for display.
T180-TRTYP is a SAP recommended field to be used in user exits to know if the document is being created, changed or displayed
If sy-tcode = 'VA02' will not work with BAPI as you are actually not executing transaction VA02.
Also just disabling screen fields for input will not have affect on the BAPI call.
You would need to ensure it through separate coding

Preventing disabling of check box - item okay in MIGO

Dear all,
In the MIGO transaction - during goods receipt for subcontractor material, when the item (incoming) is checked as item okay - automatically the child material (Material sent to subcontractor) is also activated thereby to enable 543 movement.
Unfortunately some of the users are disabling the check box (for the material sent to the subcontractor). This prevents depletion of stock from the subcontractor but inflates the stock of the incoming material.
Is there any way - either by authorisation check to prevent users disabling the check box or other methods?
Experts suggestion is required in this regard.
Thanks in advance.
Regards,
M.M

Hi Magesh,
it is possible. use Badi enhancement
MB_MIGO_BADI goto
IF_EX_MB_MIGO_BADI~POST_DOCUMENT
tell your abaper to put the logic like
parent ID and subcomponent ID need to select
if either of two is not selected
then error message will prompt not to save the GR doc since subcomponent is unselected.
reference field EKPO check PSTYP
hope this help you.
regards,
Maia
Edited by: Maia on Apr 18, 2008 3:07 PM

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

Disabling the Check for Update feature in 10.1.3

Hi,
I work at a government facility that has tight security restrictions regarding downloading software. We are about to prepare a software delivery package for JDeveloper 10.1.3 that will let our IT department install JDeveloper on all of our developer workstations. One thing we would like to do as part of this deployment package is to disable the Check for Updates and PlugIn feature of JDeveloper. Is there a setting in a configuration file that controls this menu item?
Thanks,
Richard

Hi,
Is the requirement to disable the check for updates feature altogether (i.e. remove the menu item), or to just disable the automatic check that happens on startup?
There isn't currently a documented way to totally disable the feature altogether, however it's possible to add such a feature in a future service update if necessary.
There is a potential way in which you can modify the behavior of the wizard such that it will always find no updates (the menu item will still be present, however). If this is an acceptable solution to you, let me know and I'll fill you in on the details.
Thanks,
Brian

Disabling a Check box

In my BSP View am using two check box.
I want to disable one check box when the other one gets checked and vice versa.
Right now am doing with some logics and with server side events.I want to do this in the client side.
In <b>Java script</b> how i can code this in my BSP page where the checkbox is created with the help of htmlb.
Kindly help me in this regards.

Hi,
put this in your documentHead:
<script language="javascript">
     function uncheckyes(){
      document.form_id.yes.disabled='TRUE';
      </script>
<script language="javascript">
     function uncheckno(){
      document.form_id.no.disabled='TRUE';
      </script>
and this in your layout (documentBody):
       <htmlb:checkboxGroup columnCount = "2"
                                     id          = "expense" >
                  <htmlb:checkbox text          = "Yes"
                                  id            = "yes"
                                  onClientClick = "javascript:uncheckno()" >
                  </htmlb:checkbox>
                  <htmlb:checkbox text          = "no"
                                  id            = "no"
                                  onClientClick = "javascript:uncheckyes()" >
                  </htmlb:checkbox>
                </htmlb:checkboxGroup>
grtz
Koen

Using Javascript to disable a check box

Friends,
I am stuck on what should be a simple requirement and I am hoping you can help.
I need to disable a form region checkbox if a field on the same form region has anything entered.
What I have done so far is:
1) On the item that determines whether the check box should be disabled I have added a call to my Javascript function "onChange="disableDefaultDisplay();" in the "HTML Form Element Attributes"
2) My javascript funcion is: (this is the basic version, all I am trying to do is disable the check box at this point)
function disableDefaultDisplay()
alert("Start of the function");
var defaultDisplay = document.getElementById("P13_DEFAULT_DISPLAY");
*defaultDisplay.enabled = false;*
alert("End of the function");
Using a combination of firebug and the alert messages I can see that function is called at the correct time (i.e. when the user changes and then leaves the field) and that the values of the variable, defaultDate are set but my attempts to disable the checkbox have yet to work!
When I look at the type of the checkbox (through the source of the page or firebug) I see the checkbox has the following "fieldset#P13_DEFAULT_DISPLAY.checkbox_group" Do I need to do anything different to disable this type of object?
Any help would be very much appreciated!

Hi Andy,
I was returning to this thread to update it with how I resolved it, so thanks for the detailed response.
In a nutshell, the solution I used was a loop through the field set(of which there is only one item in it) and disabling it.
Where you say:
Secondly, checkboxes are, as you have seen, wrapped within a fieldset tag. The fieldset tag has an ID of the page item name. Each checkbox within that tag has its own ID value, which will be the fieldset ID plus "_n" (where n is a sequential number starting from 0) - thus, the first checkbox will be, for example, "P1_CHECKBOX_0", the second will be "P1_CHECKBOX_1" and so on.From my searching for a solution I had expected to see something like that. But the source for the item I was trying to disable is shown below and I can't see any numbers after it.
Do you know why? Is it because it is the only item?
<fieldset id="P13_DEFAULT_DISPLAY" class="checkbox_group">
<input type="checkbox" name="p_v18" value="Y" id="P13_DEFAULT_DISPLAY" /></fieldset>
Regards
Ian
Edited by: IanC2 on Feb 8, 2009 8:07 PM
Edited by: IanC2 on Feb 8, 2009 8:08 PM

HR ABAP Custom Authorization Check

Hi all,
We know that Implicit authorization check is carried out. The system determines whether the user has the authorizations required for the organizational features of the employees selected with
GET PERNR.
I have a question, if we create a custom authorization then, whether this custom authorization is checked or not.
Thanks in Advance.

There is no difference in the coding of the check, which as RJ has stated needs to be somewhere at the correct coding location... otherwise it is going no where.
Some special differences are:
- The object class of the custom object in SU21 => Authorization objects in HR cannot be deactived context specifically in SU24. You can create custom objects within SAP classes.
- Depending on the transport type of your system, you will have to maintain transaction SU24 with a check indicator for the object - so make in known that the transaction has the capability to check the object. This does not affect "customer" systems, but is still a very good practice for the same reason that SAP forces it in their own development systems.
- Additional object checks in SE93 (which are typically "plausibility" checks) are not subject to this restraint. The check is always there, and your ability to bypass it is limited if you check the tcode authority of the caller at initialization of the (called) coding context. CALL TRANSACTION will skip this check, unless the called transaction is sy-tcode already (as it is in variant transactions... which urban legends claim to be secured to use for CALL TRANSACTION).
This concept is to a large extent influenced by SAP's own development guidelines and "settings" - but it is advisable to understand them and the intended authorization concept - to be able to create consistent customer implementations of SAP products.
Of course there are exceptions to the rules... but they generally cause problems and sooner or later need to be corrected as well when the auditors get hold of them....
Cheers,
Julius
Edited by: Julius Bussche on Apr 27, 2009 9:03 PM

Authorization check in LDB PNP

Hi All,
I am using logical database PNP in my report program and GET PERNR to fill the infotype tables. Infotype level authorization checks are performed but not Org data level (organizational assignments). The role assigned to me has access to data of specific personnel areas but I am able to retrieve data of all personnel areas (this was maintained in the authorization object P_ORGIN).
I read the level of simplification should have a value 1 in the authorization object P_ABAP for Org Level authorizations to be performed. I have updated my role but still org level authorizations are not performed.
Can you please let me know if any special setting are to be done like in Tcode OOAC or set some flags/parameters in the report program to perform org data level authorization.
Any information provided will be really helpful.
Thanks,
Pavan

Hi,
A separate ID was created in an environment similar to production and proper authorization were assigned to it (I mean roles with authorization objcts P_ABAP - level of simplfication 1 and P_ORGIN - restricting based on personnel area). Still Org level authorizations were not performed while using the LDB PNP. Is there anything I am missing?
Thanks,
Pavan

Authorization checks for PNP LDB

question : how to validate authorization checks for pnp logical database?
2 nd question: hr report
this report is basically for salary survey. in this i had so many fields can any body let me know how
can i form the internal tables. and i have to display overall 150 fields in csv file for that
how can i take in to the final internal table.
what is the logic behind this:
T71JPR09-JOBCODE
PA0000-PERNR
HRP1000-STEXT
P0006-PSTLZ
PA0008-ANSAL * 100 / PA0008-BSGRD
PA0015-BETRG
PA0761-LTEXT WHERE PA0761-CPLAN = LTI PLAN PSU YEAR 1
PA0761-GRADT WHERE PA0761-CPLAN = LTI PLAN PSU YEAR 1
PA0761-ZZGRANT WHERE PA0761-CPLAN = LTI PLAN PSU YEAR 1
PA0761-LTEXT WHERE PA0761-CPLAN = LTI PLAN esu YEAR 1
like that i had.
please give me the steps how can i proceed.

Hi,
The PNP database will take care of authorization check. It will not execute if used does not have authorizations.
Hope this helps.

CRM - Process Flow of Authorization Check in Business Transactions

Hello Folks:
I have implemented CRM security using Process Flow of Authorization Check in Business Transactions.
What I have in place:
CRM_ORD_OP (inactive, don't want access to own documents)
CRM_ORD_LP (inactive, not using standard org level values Distribution Channel, Sales Group, Sales Office, Sales Organization, and Service Organization.)
CRM_ACT (active)
CRM_CMP (active)
CRM_ORD_OE (active, restricted to display with dummy value ' ' for Distribution Channel
Sales Group, Sales Office, Sales Organization and Service Organization, as we are not restricting on them)
CRM_ORD_PR (active and restricted to display)
Issue:
Restrictions to display for documents works fine when using CRM backend system and the system throws out a message that you are not authorized to change. But, when i come in through Portals (PCUI), i dont get the display at all and it throws out a message insufficient access authorizations.
Traces on backend CRM reveal failing on change access for CRM_ORD_LP and CRM_ORD_PR, which we dont want to give out b/c we dont want to provide change for documents.
OSS notes to SAP have resulted in no results....please advise what is wrong here.
Thanks
KT

Thanks for the Priyanka for the reply, but what you mention is not correct.
BSP errors are different from what I am refering to.
The issue is still open...and looks like a SAP bug, which even they havent been able to fix so far.
Regards,
KT

Disable authorization check RH_STRUC_GET

Similar Messages

Maybe you are looking for