function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
BradDBradD 

How do I run an s-control as an administrator?

I want to run an s-control that will be invoked by a standard user, but the s-control needs to update a field that's only accessible to an administrator... is there a way to "log-in" as an administrator in the background so the s-control can run? I thought you can do something with a session id of an admin, but wouldn't that expire eventually? Someone please help, thanks! -Brad
TCAdminTCAdmin
Hello Brad,

I'm not familiar with a way to do what you are looking for as in the login.  What I have done in the past is to unlock the field so that all profiles can access it.  Then create a custom checkbox field that isn't on the page layout but is available to all users.  You can then create a validation rule that will prevent the user from changing that first field unless the checkbox is set to true.  You can then use the sControl to set the value to true and modify the field in question.  It is a bit ungainly but it will do what you are looking for.

I also setup a workflow and field update that will change the checkbox from true to false so that you don't need to worry about it remaining in the true state.

Let me know if this helps.
gsickalgsickal
You can simply insert a login statement with your admin userid and password.  This will "redirect" the current userid and session from the user who invoked the scontrol to the admin user and will allow you to do whatever the person with admin privledges can do.  The problem with this approach is that your admin userd and password are exposed and hardcoded in the scontrol itself.  There might be a way to store the login credentials in a protected custom table somewhere that anyone can read but is not exposed on any layouts and thus for all purposes works... Maybe someone has another way to securely store the credentials somewhere on the server?
TCAdminTCAdmin
Hello gsickal,

When you use this method to overwrite the existing user's login, does it log the admin out after?  Will you have to do a log out after so the user is not logged in as the admin, with the admin permissions?
gsickalgsickal
yes, there is no logout api call so I don't think the admin user gets explicitly logged out, you would have to explicitly relogin as the initial user in your scontrol, but again the problem is the password is in the scontrol code.  so your scontrol would look something like this.  Not the best way since passwords are stored in the scontrol, but you could easily extend this by writing some code to retrieve the passwords (and or admin userid) from a protected admin table in salesforce...
 
...
//execute statements as current user who invoked scontrol and save user info
var userId = "{!User.Id}";
var userPswd = "mypswd";
...
//login as admin to do things that need this permission
var result = sforce.connection.login("adminUserId",'adminUserPswd");
...
//execute statements that require admin credentials
...
//log back in as original user to execute the rest
var result = sforce.connection.login(userId,userPswd);
...
//execute statements with original credentials
TCAdminTCAdmin
gsickal,

Thanks for the information.  This is what I thought would happen.
sfdcfoxsfdcfox
I know I'm kind of late on this topic, but...
 
Remember, in Enterprise Edition, fields do not need to be on any page layout anywhere (thus effectively invisible to mere mortals users), so that the field can effectively only be updated via the API (that is, your script). Odds are, the user won't even know the field's there to mess with it. Better yet, use a workflow field update to update the field... in most cases, you can use a formula to derive your final values and workflow field updates ignore field level security without compromising your own administrative permissions.
 
~ sfdcfox ~
gsickalgsickal
so are you saying we could store a superuser id and password and retrieve these from private fields in a table somewhere?  even though they could only be updated via the api they could still be read from the api though, right?  what would your recommendation be to run portions of an scontrol as as admin without hard coding the admin userid and password in the body of the scontrol?
sfdcfoxsfdcfox
No, don't store your username and password anywhere. That's asking for problems. Simply remove your field from all page layouts, but make the field visible on "Field Level Security". Or, again, use a workflow rule to have that field updated using a Field Update. I actually used this trick to make a hidden "Credit Card Number" field that only displays to admins, but normal users see just something like: "Credit Card: ****1234" so they can verify the last four of the card without seeing the entire number; they can type in a new number to update my hidden field, and then they see still only "****5678" after updating it (or whatever the last four was). On my report, I would only ever see the real number (as an admin) by hiding the fake field so I couldn't see it, and then using a field update so when I update the real number, the fake field gets updated too.

~ sfdcfox ~