Role option to avoid conflict


VIP Member
Hello there

I have situation and want to know what option you will pick or there are other options.

Role 1 seq 100
Role 2 seq 200

Role 2 is super power user and have access to the *All objects except the object related to CNC
Role 1 is the inquiry role and has access to many objects as view only e.g address book.

When super user go to Address book they can not see Add/delete action and the reason is the different multi record defined (*All and specified objects) even the Role 2 has higher seq, the Role 1 can not let user to see action buttons.

Here are the options and need to know what is the best way to handle with less impact.

Option 1
Let power user to login only with the Role 2.

Option 2
copy all the objects from Role 1 to Role 2 and give access to the objects so the Role 2 seq will win as same objects will defined in both.

Option 3
Create new role and give access add/delete/view to objects and remove Role 1 from user.

Any suggestions?

Every user should have only one role. The whole "Role chooser" thing smacks of bad design.

If you are having trouble with it, purchase one of the two popular JDE security products.
Above I said the issue with Action Security type with *ALL with Role 2 is the issue but it is not:

The issue is only with Application Security type when it says 'N' to Run/Install in Role 1 and with *All Role 2 . I can simply delete those entries from Role 1 by making sure why it was there in the first place.

I like that approach and I have achieved with Finance group, it is long Journey but getting there.
Challenge comes when managers want specific user not to have access to some objects and I don't like user level security. So approach to have create more roles.

Hi Ad,

Yeah, it can be a pretty horrific journey. I mean you really need to map 1 to 1 between Job Roles (as per HR) and the JDE roles. I converted 360 users from a multiple role per user setup to a single role per user and it took about 1.5 years part time .. I was doing other projects in the middle of it.

On the plus side, when you are done you can now scale quite easily as the work is defined per job role and you can also avoid user level security entirely.

It's too bad companies don't spend the time to set things up correctly in the first place. I supposed people have been saying that forever..

happy friday


The key is whether you allow the role chooser or force *ALL roles.

If you are going to use multiple roles (the advantage of this is that less security maintenance is required because changes can be done by changing user role assignments instead of the security itself) it is normally a good idea to force *ALL. We generally recommend this approach because its actually easier to do with the right technique and you get far better results in the end. With this method, the effect of the various roles gets combined but you do need either a tool like ours or a good design to avoid conflicts.

If you allow users to choose their roles, then as well as users maybe being more familiar with this approach, you must make each role complete in itself. Ideally here you would force users to choose a role rather than allow users to either choose a single role or sign in with *ALL. The problem is JDE doesnt allow such forcing and so enabling the role chooser to be used doesnt prevent signing in with *ALL. For this reason you need really to assign only a single role per user and live with the fact that a) there will be more security maintenance and b) from a compliance/Sod point of view the design will be open to criticism.

Obviously without understanding if a) the role chooser is forced and b) this is deny all/grant back or open system/deny specific its difficult to be more specific.