You need to sign in to do that
Don't have an account?
D_M_C
Stop users from updating their own profiles?
I have the requirement to disable most users (all users within a custom Profile) from being able to update their own profile - we will be importing that data from another, master source. Is this possible?
There is a way to achieve this through Apex Coding.
A trigger on User Object after update, we can use the UserInfo Class to determine the current running user's Id and cross check if his user detail is triggered. following is a pseudo code of the concept
let me know if this helps; if this solves your question please mark this as solved so that other users may benefit
All Answers
Hi,
If you want to restrict the modification of user details by the users of the particular group, I suggest you uncheck the permissions for the particular profile.
To break it down Navigate to Setup => Manage Users => Profiles => (select the profile you want to revoke permission ) => edit => Under the section Administrative Permissions uncheck "manage Users Permission" and "Reset User Passwords and Unlock Users ". Then the users under this profile would not be able to edit details of other users.
In addition as a best practice, We might need to assign certain users within the above profile to edit user details, in that case I usually prefer to use permission sets in addition to above change.
Add these permissions in to a permission set and assign the permission set to that particular user, and he will be an exception and will be able to edit the users details
please let me know if you need more clarity !
Good day
Thanks for your quick reply. Unfortunatelly, your guide shows me how to stop users from modifying other users - I have to stop a user from modifiying their own profile. I assume this is not a commonly used feature and I don't see a simple way to do it.
Please note that disabling "View Setup and Configuration" under a profile does not stop them from modifying their own details.
There is a way to achieve this through Apex Coding.
A trigger on User Object after update, we can use the UserInfo Class to determine the current running user's Id and cross check if his user detail is triggered. following is a pseudo code of the concept
let me know if this helps; if this solves your question please mark this as solved so that other users may benefit
im confused why the trigger is on "after update"
There was no specific reason for choosing after update, and I do sense the point you're trying to put forth,
Even though after update is executed after the preliminary save to database, once the addError is used and if the record is marked with an error, the DML does not complete and hence the data is not saved and is rolled back
if you'd like to refer :http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_sobject.htm
but does the approach suit your reuirement? if it solves the problem mark it as solved, in future others can refer to this.
Good day !
I apologize if it seems like I'm stepping in here, but I'd like to make a point. Technically, any validation that generates an error should be a "before update." Why? Because performing validation on an after update creates an exception instead of a normal user error message. While it's trivial, and technically doesn't matter (as the desired end result is the same), the error that will be returned is not the error you wanted to show, but instead an error that an exception occurred because the error was added. Any "before" event should be concerned with data validation and same-record data manipulation, and most likely callouts (and in some rare "chicken-egg" scenarios), while "after" events will generally handle some situations such as updating related records, queueing batch jobs, and so on. There is a reason why there are two phases, and you should try to honor those reasons.
Edit: I'd like to point out that I specifically happen to know of this condition because I had a project where it was undesirable to be able to revive deleted records from the Recycle Bin directly, and of course, there is no "before undelete" event, so I had to use the "after undelete" event, which caused a completely different error to occur.
Edit: And the link just posted states this:
When used on Trigger.new in before insert and before updatetriggers, and on Trigger.old in before delete triggers, the error message is displayed in the application interface.
Note that the documentation clearly states that your error message will only be displayed when using a specific sobject instance (either Trigger.new or Trigger.old) in specific trigger modes (before insert, before update, and before delete).
And it makes sense