PFCG role status after transport

[AlainR2000]

Hello all,

When any given role in PFCG is transported to QA or Prod, even though the role and profiles are successfully generated in DEV, all tabs are green light, when it gets to QA or PROD, it falls into a status of "Current version not generated". The authorization tab turns yellow althought no objects are opened or to be generated. Running a Mass Generate fixes the issue but I never had that problem in all other companies I worked with. Does anybody know what needs to be done so I don't have to run a MAss Generate each time a PFCG role is transported ? We are running version ECC 6.0

Thank you all.

[henrik]

Are the roles derived? Seen the problem when not transporting all the derived roles when transporting a changed master...

[AlainR2000]

Henrik, you are absolutely right. Most of the roles are derived and after taking a closer look, all derived roles being transported falls into a yellow light authorization button on the target system. Any fix for that or it should be considered a normal behavior for derived roles? Thank you !

[jurjen]

Like Henrik stated, transporting the master and all it's derived roles should fix the issue. Otherwise you can regenerate the derived roles from inside the master role in PFCG.

[berryd]

I hate derived roles - they are more trouble than they are worth and this is one of the reasons - another being object level over-writes danger.

We had major issues with transports and decided to break the links to the parent and maintain them separately - generation in PRD should not be required/allowed anyway.

[henrik]

If you are careful and consistent in how you maintain your roles, derived roles can be very useful. Yes, there are issues, but I prefer dealing with the issues as opposed to dealing with the maintenance of a large number single roles, which for me causes a lot more issues - mainly in terms of workload

[berryd]

Hi Henrik

I do hear what you say about the benefits of mass updates to dozens or hundreds or derived roles but...

Given the dubious nature of derived roles (adding a new transaction which imports cost centres, storage locations or release strategy objects unexpectedly) I would avoid these and use alternative methods if possible - not sure if the profile issues that this thread originally asked about has been sufficiently answered so far so would be more than happy to find out how to 100% clear any possible issues please?

They are fine for initial rollouts but a complete pain in the butt for long term maintenance - having to restore from an older PRD version isn't fun and having a controlled (and safe) method instead has to be better than a 'OMG' senario when you have to re-transport perfectly transported roles to clear profile gen. errors...

[henrik]

Hi berryd,
Not too sure why you think they are of dubious nature... They really behave the same way as any other role - except you can screw up a lot more roles a lot faster than having to do one at a time Nothing is imported into derived roles, that is not added through the master role.

If you make a mistake in the master role, it will go through to all of the child roles. But as long as you keep the design clean, that is not really a risk. Or at least, you can clean it up again quickly when (not if) you screw up...

I do agree that after go-live, there may be some issues if you have to tailor the roles to different business units. But if you don't need that flexibility, the derived roles are hard to beat, in terms of maintenance efforts.

For the transports, I don't find it to be a problem either - once you get used to transporting all the derived roles, nothing really goes wrong - at least nothing that couldn't go wrong with individual roles as well...

So what problems have you experienced with derived roles? Not too sure why you are saying that release codes or cost centers are added unintentionally/automatically? I haven't experienced that

/henrik