Role based Security E8.9, again!

Hi List,
here´s another fun fact about E8.9´s role based security. We
found that whenever a user has more then 47 roles to his/her profile he/she cannot log on to the system any more.
Ok, I admit that 47 is a lot of roles for one user. But there should be no limit as low as that.

Any comments?

Thanks Gerd
E8.9 SP3, AS400, WTS[laugh]

I currently have a SAR open related to this. If a user has more than 32 roles, they can no longer access IV, BV and OMW. The system blows up and shuts down. No error message or anything.

They have been working on it for months now.

32 or 47 roles? Really guys c'mon. Remember when we could have only 1 ROLE? I suspect that JDE/PSFT will publish a limit of 30 roles or something.

Now what user has the 32 or 47 roles? A system administrator account that you're using to configure the roles or is this an actual user? Just curious.

Colin

In our case, we do not need that many roles. The JDE App consultant added himself to all of the roles in the system to set up task menus. It is not truly an issue with us, but we thought we should bring it up to Denver.

I have a question sort of on this topic. How is everyone modifying existing roles (e.g. activating existing parent/child tasks) in 8.9? It seems to me you must log in with an id belonging to the role to make changes to it and thereby inheriting the security set up for that role. If a role is locked down (e.g. *ALL/*PUBLIC no access with specific applications opened up) and has no fine cut access it prevents the admin user from make the necessary changes.

We have deny all security in place but do not use *Public Deny all because we are in the middle of a Go Live. How we handle this problem is we created:
1. A DenyAll role which has a *ALL/Deny at the application level. Environments TS, PY, PD
2. A DefRole which has all of the Search/Select forms, etc that you need to run EO. Environments TS, PY, PD
3. Numerous User roles for varies job functions. Environments TS, PY, PD

We are leaving DV open for developing. No end users have rights to DV.

By doing our security this way, we can give DenyAll security to some of the users and have open security for the managers/consultants who are still setting up the system.

The only catch I have hit so far is if a Developer has the DenyAll(TS, PY, PD) role and the RPTWriter(DV) role for doing development, the DenyAll is still being applied to DV when it is not supposed to be. There is not a record in F0093 for that role/environment combo, but it is still shutting them down. If I remove the DenyAll role from the user, everything works fine. I am currently waiting to hear back from our JDE CNC consultant about this issue before I bring it up with Denver.

Anyone else experience roles not following the environment the are set for?

Sean Selman
CNC and Application Development

Colin,
you are absolutely correct, that´s a lot of roles. In my case, I do the consulting and then people come up with that kind of stuff. What can I do? I have to remain somewhat polite to my client.
And you know what, the user wanted 60 roles. Good that E8.9´s limits stopped us in time.

Cheers, Gerd

Sean, look at SAR 6927608 for this issue. Try to set the DEFAULT environment and pathcode in your WS´s JDE.INI to the environment you are actually logging in to.

Gerd

Thanks for pointing that out. I knew I read something like that a few months ago but I forgot the details. I believe setting the INI file would fix the problem (according to the SAR). We have users that in multi-environment so setting this each time in the INI file is not a good solution. Hopefully they get it fixed soon.

Well, JDE/PSFT claims this default environment SAR was fixed in SP2_F1 according to the documentation. We have 8.93_C1 (SP3_C1) and the problem still occurs. Looks like they forgot to include this fix in the latest service pack.

Sure, but some folk I have been working with, and am having difficulty in persuading, have an idea that they wish to group a set of applications e.g. " Manual Payment Processing " ; "Automatic Payment Processing" ,as ROLES ?!? Then , continuing they will add other sets of Apps. required for A/P Clerk functions as ROLES, and then attach all these ROLES to the APCLERK User. So the APCLERK user will sign on 'playing' All ROLES. Firstly they will run out of ROLES, secondly I thought a ROLE was designed to be a Job Function, not just a part of a job Function. Any other views ? Am I on the right track ?