0

We will delivery in our production org and we want to avoid users to log while the time of reconfiguration and delivery.

It is recommended to modify Login Hours but we have a lot of profile to modify if we do it in that way, and I would like to automate that process. It's not possible to modify profile in APEX as DML is dissable on profile.

Is there a good practice to apply here?

3

You can run a quick Apex script on either UserLogin or PermissionSetAssignment.

WARNING: If you modify these scripts, be careful not to lock out your own login. Support would be required to fix the problem.

Example #1

UserLogin[] logins = [SELECT UserId FROM UserLogin WHERE UserId <> :UserInfo.getUserId()];
for(UserLogin login: logins) {
    login.IsFrozen = true;
}
update logins;

Example #2

PermissionSet lockoutPerms = [SELECT Id FROM PermissionSet WHERE Name = 'LockOutUsers'];
PermissionSetAssignment[] assignments = new PermissionSetAssignment[0];
for(User userRecord: [SELECT Id FROM User WHERE IsActive = true AND Id <> :UserInfo.getUserId()]) {
  assigments.add(
    new PermissionSetAssignment(
      AssigneeId = userRecord.Id,
      PermissionSetId = lockoutPerms.Id
    )
  );
}
insert assignments;

You can use the Apex Data Loader as well, or any other API-enabled tool to create/modify these records. To reverse this when you're done, simply update the UserLogin records, or delete the PermissionSetAssignment records.

2
  • I have an error when I try your first exemple : Line: 5, Column: 1 System.DmlException: Update failed. First exception on row 0 with id 0Yw1t000001QBaxCAG; first error: UNKNOWN_EXCEPTION, You cannot edit this field: [] and I don't understand why – Badbaxx Jan 22 '19 at 9:25
  • ok, I finally found why ^^ salesforce.stackexchange.com/questions/234822/… – Badbaxx Jan 22 '19 at 10:44
1

To complete the answer, we finally we decide to use loginFLow. The advantage of this is not to freeze or unfreeze users who have been in a different context than the setting in production. more details

0

Why take the pain & risk of self logging/locking out with code. Safest bet is to always use/think OOTB first and that is Login IP ranges. Before we jump into the solution first thing first is to determine what active sessions your users on. You can carefully decide based on your application to remove all active sessions and force them to re-login. Now simply add 0.0.0.0 to both start and end addresses for every single profile where you have to lock users from accessing other than Admin profile. Once you are done with your tests post deployments, simply delete that one IP range with 0.0.0.0, boom your application is live.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.