controlling env access via UserID or by role

Can I limit access to a particular environment(s) by specifying the desired env(s) on the UserID ? I have tried
this but the processing precedence rule of "most specific trumps least specific" (which I think is generally true in E1 security) doesn't seem to apply. Example: security on a specific UserID always trumps security in a role, which always trumps security for *PUBLIC. So, if USER1 has (only) env JPY9 specified in her profile but uses a role that is valid in both JPY9 and JQA9, wouldn't you think that JQA9 would/should be denied ?

Thank you.

In Xe and 8.0 this is true, user environment mapping takes precedence over group but I am not one of the fortunate to have upgraded to 8.11 as yet so I don't know if Oracle lade changes to that...if they did it would be nice to know why.

we are on 8.10; we have the same problem; the security seems to work OK on a fat client but definitely not on the thin clients; it was reported to Support a couple of times (Case # 3936458/3976388); it is a major problem because we have users that sometimes think they are in the test environment and start mucking around, just to find out they did everything in production. Oh la la! Headache, headache, headache! Please browse thru these cases. This is how the last case ended up:
"I think that bringing the fat client "behavior" to the html clients was the intent of the original SAR, but the direction for Development is toward web - exclusively, and currently this lends to some unusual and interesting difficulties with regards to security. In fact, they have since actually taken away functionality somewhat in 8.94 with respect to taskviews and multiple roles.

I believe that once the E1 product is firmly established in web-only instances (i.e. 8.11 and beyond), that they will be able to concentrate on one runtime engine for development. This will then open "doors" to seemingly more practical functionalities for the customer.

Regarding your second security table thought - some customers have elected to create a second F00950. It is not supported here, however, it is also not prohibited. You are correct to assume that this will be a significant maintenance scenario. My advice is to begin working with the platforms team if you need guidance, although they will likely reply by advising against it.

If you are interested in lobbying for better environmental control over users, I would recommend contacting your account rep, and having them act on your behalf. They will be able to contact product and marketing managers for E1. Refer to the SAR I mentioned (7772396) as a beginning point, and feel free to refer to this and other case numbers as you see fit."

Hope this helps.

It now seems that on 8.94 webclient you CAN control env access at the UserID level, and that it DOES take precedence over the env(s) specified on the login role.

My mistake was that I tested prematurely -- security cache clear alone was not enough -- JAS bounce was needed before the envs on UserID took effect. Because now (after JAS bounce), users gets "An unknown JAS error has occured" when trying to login to env that is NOT listed on his/her UserID.

So, I take this as indication that user is being blocked from env. I better inspect logs carefully to make sure this is what's happening. It would be nice to have consistent messages (since fatclient says "Invalid role/env combination").