RE: Keeping users out
Date: Mon, 23 Nov 2009 12:37:49 -0500
Message-ID: <21F336E0438E410289F3CCA239620A1A_at_rsiz.com>
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of dave
Sent: Monday, November 23, 2009 11:47 AM
To: andrew.kerber_at_gmail.com
Cc: Sharon.Kovac_at_rotometrics.com; oracle-l_at_freelists.org
Subject: Re: Keeping users out
On Mon, Nov 23, 2009 at 11:22 AM, Andrew Kerber <andrew.kerber_at_gmail.com> 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.
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Nov 23 2009 - 11:37:49 CST