Who changed the rules?

In 8.12 (or ealier releases) did the User->Group->Public rule change for environment access?

Back in the old days, when statues of Ed existed in the wild, if you assigned an environment at the user level, the evaluation stopped and that was the environment access. Now it seems as if environment access is not even evaluated at the user level but at the Role level.

Any feedback?

Yep Jeff you're right. So the question remains why do they even let you do it at the user level?

The only time the user level environment config is useful is for an upgrade or migration. Otherwise with security server running it just ignores it.

Colin

[ QUOTE ]
Yep Jeff you're right. So the question remains why do they even let you do it at the user level?

The only time the user level environment config is useful is for an upgrade or migration. Otherwise with security server running it just ignores it.

Colin

[/ QUOTE ]

Thanks for the reality check.

A little irked with Oracle for changing the rules. I may just get Chuck to roundhouse kick them back into JD Edwards.

Maybe an 8.12 thing? That doesn't make sense if they're using the same tools. Perhaps its a bug in the tools? I know with utmost certainty you can assign environments at the user level with 8.11 SP1. It isn't cumulative, however. If you assign only one environment, its the only environment the user can login to...

Strange. User assigned environments don't work for us and we're running 8.11 SP1. I'm running 8.95_K1 with it. Maybe that has something to do with it ... I don't know.

But, I do recall raising a stink with Oracle about this issue when I found out it no longer worked for users after installing 8.11 SP1.

Oracle simply stated that they never intended environment assignments to work at the user level and that they finally got around to fixing the problem (which really wasn't a problem until they "fixed" it).

Sometimes, it is just impossible to reason with them.

How very nice of them to "fix that problem." We don't use that functionality for 99.9% of our users, but we do occasionally have to build in an exception for a user to access a specific environment. I didn't realize that that was a bug. How very nice of them to fix that "bug" after all this time.....

Jeff,

From my experience, it was always like what you are describing: if there's anything at the Group level, it takes precedence, if nothing then the User settings are used. This has always been different from any other security setting.

If it accidentally did work the other way around in some SP's, then it was a bug.

Not a very intuitive design, I totally agree. It goes against any reason. But it's certainly how it works at all my customers' on a variety of releases/service packs.

Alex,

Maybe things worked differently down under (doesn't water swirl the other way in the southern hemisphere?), but security goes from user, to group, to *public. Environment overrides are not defined in the security table. If you define a set of environments for the user, that overrides the set of environments for the group or role. That is the rule for XE and below.

Gregg Larkin
North American CNC and JDE Security

Gregg's description is exactly how it works for us. We are on 8.10, 8.96_H1 (recently upgraded from 8.94_O2). We assign environments for all of our users, as we have 24 PD environments (each entity has their own Business Data, Control Tables and Versions, but share Objects).

Dave Schleicher
LOGIS

I just tested this with 8.96_I1 Tools on 8.11. If I add an environment override to my userid, it is the only accessible environment. Tested both fat client and web.

Fat client jde.log when attempting to sign-on to PY811 after adding only DV811 as an environment override to my user:
Could not validate role environment pair in SignOn_ProcessOK:validateEnv

Web jderoot.log:
can't login due to invalid environment override

[ QUOTE ]
we have 24 PD environments

[/ QUOTE ]

why ?

We host, maintain, upgrade and support E1 for 24 entities, and because they all have unique setup (in both Finance and Workforce Management) and never need to combine data on reports found it was best to set them each up with their own environment.

Yes, that's obviously how security works, but I am under impression that environment access specifically was working in the opposite direction.

Did you say water? What water? - we have water restrictions here now with this crazy weather ;-(

Anyway, if it was designed one way and then broken to work another way and then fixed again, to potentially work in some third way, then this will all depend on your SP ;-)

Alex,

Want some of our water? It's been raining on and off for hours on my side (and hemisphere)of the planet. In XE, environment access has always worked user first, group (or role) second. It sounds like they made a change in a recent tools release.

Gregg

Thanks. I wish ;-)

Ok, maybe I confused the order, or maybe I was using untypical service packs all along. I'm not so sure any longer and don't have time to test...

[ QUOTE ]
Thanks. I wish ;-)

Ok, maybe I confused the order, or maybe I was using untypical service packs all along. I'm not so sure any longer and don't have time to test...

[/ QUOTE ]

Environment access worked just like security did (U->G->P) up until ???

From the responses here it appears that the deliminating point is 8.11SP1 but that doesn't make sense as this change would seem like a TR change.


Ideas anyone?

My 2 cents to increase confusion..
From my experience in 8.95_O1 (8.11SP1) if you assign enviroment(s) to the user, it will indeed allow access only to that enviroment (assuming that user has roles that have access to the particular enviroment). BUT for the Web server access it only works for the particular web server instance.
So lets say you have 4 enviroments/Path codes - PD and QA running on webserver port 81 and DV/PY running on port 82.
If particular user has JPD811 assigned to him, he will only see JPD811 when signing on to webserver:81
The same time he will see both JPY811 and JDV811 when signing on to webserver:82 although none of them are assigned to the user.

Fat clients work as expected

Apparently this was fixed in sometimes in 8.96, since in 8.96_F1 regrdless of the number of ports or webservers, user will only be allowed to login to the enviroment assigned to his user ID

All of the above is applicable to Websphere 5/6 running on Windows boxes, I don't have experience with OAS

Nice of Oracle to "Fix the glitch" Someone tell Melvin.

I am having a similar issue with clustered OAS on 8.11 8.96_O1.

I added a new environment and everything works fine up until I try and log into the web. The user, JDE, which work fine on a fat client, will not log into the web. I get the "Invalid Environment Override" error message, which is also spelled "Invalid Environemt Override" in the JAS.log.

Misspelling aside, I have all of my environments set up for both the user and role. My environments that existed before the new one was created are all fine, but the new one won't log in only on the web. There are no other error messages.

I have confirmed all of the OCMs are right for the J environment, so I can only assume this issue is related to what is going on with this thread.

Any ideas?