Whenever possible, I leverage the out-of-the-box Salesforce functionality to implement the desired functionality. One Lightning development feature I’ve used recently is the e.force:editRecord event. In a Lightning component, you can fire this event with a record id and that record’s default edit page will open in a new modal.
That’s great and saves a lot of custom coding, if that’s acceptable. However, after someone edits the record successfully, you’ll want to probably take some action such as updating the display to show the latest edits.
Problem: The force:recordSaveSuccess and force:recordSave don’t fire after the record is edited successfully, at least in Winter 18.
Solution: Use the showToast event to take action after a record is edited successfully.
In the handleToastMessage function, the code is checking for a specific “object saved message” and if it’s found, some specific actions are taken.
If you have a better way of doing this, please let us know in the comments!
Recently, I ran into this use case:
Show a link to a Visualforce page only if the current user has access to it. This is usually done for a pilot or a dark launch scenario so that a subset of users only have access to a feature.
Originally, I thought I was going to have to implement this through a custom permission or some other configuration setting without being able to use out-of-the-box visualforce page access through profiles and permission sets. Needless to say, I’m glad I stumbled across the How do I find out if a user has access to a visualforce page through apex? stackoverflow post. In it, Gennadiy describes how one can use the following SOQL to query the SetupEntityAccess standard object to see if someone has access to a given Visualforce page or not.
If the accessSettings list has any records, then the current user has access to the desired Visualforce page. If there are no records, the current user doesn’t have access to the page.
This works with the page being granted access through either the user’s profile or a permission set, despite the ParentId being looked up against the PermissionSetAssignment object.