Quantcast
Channel: SCN: Message List - Security
Viewing all articles
Browse latest Browse all 5338

Re: Demoting an org-level - what to transport and when to do so

$
0
0

Hi Marc,

 

Thanks for stretching your memory all the way back to 46C for me...  ;-)

 

Yep, it looks like the process you followed is the one which SAP left us with. But I don't want to run programs which change SU24 and Roles and config in PROD... something tells me that is not a good idea.

 

My problem is that someone accidenturely promoted all fields they wanted a * in to org.levels so that the auths are all standard. These are were now mostly "Changed" status and SU24 broken. Seems like they went to ADM940 but were not listening all the time...

 

So, it being a Sunday yesterday, I eventually fixed it so that I could test before the users arrive on Monday morning:

 

  • Run PFCG_ORGFIELD_DELETE for the fields which converts USRORG, USVAR, SU24 and affected PFCG roles and sets the auths tab to "red".
  • Create a workbench Transport with R3TR/TABU/USORG/USVAR/USVART table contents and keys = * -> transport it through to QAS and PROD.
  • Run SU25 step 2b to find fields which had been maintained which do not relate to this org.field fiasco.
  • Run SU25 step 2c to find and convert the roles which are affected AND we still want to keep them (re are rebuilding all the roles anyway).
  • Run SU25 step 3 and transport all SU24 data through the landscapes to sync the proposals.
  • Transport at the end all roles which are affected and need to be kept through the landscapes.
  • Other roles will correct themselves if we ever have to do maintenance on them before they are replaced completely anyway.

 

So this was my solution, but I would still be interested if someone has a better approach or whether there is an official way to correctly do this?

 

Cheers,

Julius


Viewing all articles
Browse latest Browse all 5338

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>