All we have to do then is look at the Permission Sets assigned to the user and the Custom Permissions assign to their profile. All you need to do is name your Custom Permission and/or Permission Set to mirror what the Lightning Component is. Custom Permissions can be assigned to a user through a Permission Set or directly to a profile. Why is this better? Not only is the component visibility criteria significantly simpler, but it’s also easier to determine who can see it. Using Custom Permission for Lightning Component Visibility ![]() Heaven forbid if your logic is complicated that you have to spend ten or more minutes trying to figure this out. With Lightning Component it could be due to one of the above options PLUS the component visibility logic. In classic, we would check record types and page layouts, Field Level Security and profiles. Plus, the CFO can’t see the same dashboard as I see even though we’re looking at the same page. Right before you’re about to close the laptop, the CEO pops his head in, cradling his “best boss” coffee mug and asks “Before you leave, when the CFO looks at this page he sees all this information and I don’t. You’re eager to shut down and go home for the weekend, maybe for a favorite meal or hobby. ![]() Why do I hate this setup for Lightning Component Visibility? Close your eyes, well actually don’t because you’re reading this. You can imagine how more complicated these component visibility criteria have the potential to become. This could have even more criteria and more complicated logic. It’s referencing only two profiles and a single username. The example we have here is actually pretty simple. ![]() Common practice is based on the user’s profile or username. With Lightning Component Visibility, we can decide if the component will display on the page for the user based on some set of criteria. Lightning Component Visibility with Profile and Username
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |