RE: Keeping users out
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <david.best@xxxxxxxxx>, <andrew.kerber@xxxxxxxxx>
- Date: Mon, 23 Nov 2009 12:37:49 -0500
While this should work, I?m not sure whether I?d want to toggle the users on
and off routinely each weekend. How do you handle maintenance vis-à-vis
running CCMGR and workflow jobs currently?
IF the office is the sort of a shop that plays ball by the rules and doesn?t
have people smart enough hack around it and simultaneously stupid enough to
not realize that they would be screwing up to do so,
then one thing you can do is swap in a page in place of the normal url that
is reached when you go into apps with a friendly message about maintenance
being on right now and the anticipated schedule. If you have a good
relationship with the users you can enhance it by declaring the formal
maintenance window but also stating each week whether you expect to use it
all. As dave mentioned swapping the login files won?t do it anymore, so you
have to swap in/swap back something at the landing zone as opposed to
somewhere in the launching process.
The business issue things Niall raised are also prime considerations to take
up sooner rather than later. Not only do you need to make sure you are not
obstructing some organizational goal, raising the issue in a timely fashion
should make it clear you?re thinking about the whole organization.
mwf
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of dave
Sent: Monday, November 23, 2009 11:47 AM
To: andrew.kerber@xxxxxxxxx
Cc: Sharon.Kovac@xxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Keeping users out
On Mon, Nov 23, 2009 at 11:22 AM, Andrew Kerber <andrew.kerber@xxxxxxxxx>
wrote:
You can run the maintenance in restricted session and grant those users
restricted session privilege.
If this is an E-Business Suite environment then this won't work since EBS
users do not have database level accounts. Their accounts are maintained
by the application and stored in FND tables.
For us the easiest method is to use the fnd_user_pkg to disable/enable
accounts in R12:
fnd_user_pkg.enableuser('USERNAME');
fnd_user_pkg.disableuser('USERNAME');
We don't have alot of users, so this is pretty simple and quick. Even if
you have a large number of users it would be pretty easy to write some
dynamic sql to put the usernames out of FND_USERS to disable the accounts
and enable the few that require access. I believe doing this may affect
workflow and concurrent requests submitted by the user, so you'll have to
look at your particular environment to make sure this won't cause issues.
In 11i we used to just rename the login html files (ICXINDEX*.htm) under
$OA_HTML/US and provide the users who required access the new URL. In the
later stages of 11i, once the switch to AppsLocalLogin.jsp this wasn't
effective.
Other related posts:
