4

In one of the triggers, they have hard coded the userid, as below. How can we avoid this?

       if(currentUser != '012300000012345PPPP' && Utils.isS == false)
       {
             //DO SOMETHING
       }
  • 1
    What is special about that user that you do not want this to work for them? If there is something special that you could use, like a new role, or a custom checkbox on the user screen, that could help give a better way of flagging them. Then, you shouldn't have to modify your code whenever a change is made. You would only need to make the user match the code's criteria. – smckitrick Sep 22 '15 at 20:04
5

If you do not want the user id to be hardcoded as a string in Apex code then you should create a custom setting and then you can query the value in the trigger.

  Settings__c settings = Settings__c.getOrgDefaults();
  if (UserInfo.getUserId() != settings.SpecialUser) {
     //do logic for all users except the special user
  }
  else
  {
     //special user logic
  }

When the special user changes you can update the user id on the custom setting. Without modifying source code.

You could also use a Custom Permission and Permission Set to control access to a section of code. Create a Custom Permission 'Special User' assign to a permission set 'Special User Rights'.

  CustomPermission custPerm = [select id from CustomPermission where developerName = 'Special User' limit 1];

  List<SetupEntityAccess> access = [select setupEntityType, setupEntityId, parentId from SetupEntityAccess where setupEntityId = :custPerm.Id and ParentId IN (SELECT PermissionSetId from PermissionSetAssignment where AssigneeId = :UserInfo.getUserId())];

  if (access.size() > 0) {
     //execute special user logic
  }
  • Thank you very much. I just did this and it works fine. I appreciate you help – PSH Sep 22 '15 at 20:04
2

Another option that avoids the custom setting would be to create a role, put the single user in the role, and then query membership of the role using the DeveloperName of the role.

  • Thanks for the suggestion. Could you please elaborate more on this? – PSH Sep 22 '15 at 20:04
  • This would be applicable if the requirement were 'if user in Role X then execute logic X otherwise execute logic for all other roles' – Developer Wonk Sep 22 '15 at 20:09
  • 2
    @DeveloperWonk With that in mind this would probably work better as a permission set. – IllusiveBrian Sep 22 '15 at 23:54
  • @Namfuak updated original answer with alternative using custom permission and permission set – Developer Wonk Sep 23 '15 at 13:00

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.