Remove "Change Owner" Quick Action from List Views in Lightning

Hello There,
 

Have you tried removing the "Change Owner" quick action on List Views? tricky isn't it?

We also have an open Idea in our Salesforce IdeaExchange community: 

Currently with out-of-box settings, it is not allowed to remove/hide this quick action on list views and removing the change owner permission at profile level has its own consequences.

It is quite understood that in many business cases, we want to limit the ownership transfer. However, the above limitation comes as a loop hole.

Here is a workaround to get rid-off the "Change Owner" button on list-view using a Utility-Bar.  This process makes use of CSS to hide the Change Owner which gets loaded from an LWC present inside Utility Bar.  Let's understand the procedure of getting rid-off the "Change Owner".

Pre-Requisites :

• Utility bar is required to be present to be present.

Steps :

• Install the below managed package in your Salesforce org.
• For Sandbox  - Link
• For Production  - Link
  
  
• After successful installation, copy the API Name of the object for which the "Change Owner" button needs to be removed on list-views and add it to the custom label "Object_Names_to_hide_Change_Onwer". 
  
  

[For multiple objects, add them into the custom label by separating them with a comma (',') operator.  If this has to be implemented for All the tabs, mention as ALL in the custom label].

• Goto Setup > App Manager and edit the app in which the tab is present.  

• Now click on "Utility Items" on the left side pane.
• Click on "Add Utility Item", search for "hideOwner" and add it.
• You can leave the label as-is or can modify it as per your need.  If you do not want to have any label, just leave with a dot "." as this is required value.
• Remember to check the checkbox "Start Automatically" at the bottom and click on "Save"
  
  
• Repeat the above step for different apps where the Object tab is present.  
• Now navigate to the tab and the "Change Owner" quick action is gone! 
  
  

You can contact me via LinkedIN for any issues while using / installing package.  Thanks for being an awesome reader and feedback is much appreciated.  

..BazingaaaA..

Things to avoid in APEX (Part-2)

Incase you haven't seen the Part-1 of Things to Avoid in Apex, below is the link

https://adityanthiruchuri.blogspot.com/2021/08/things-to-avoid-in-apex.html

Let us understand few more tips / tricks in this post.

1. Use '==' over 'equals' whenever required

We all know that APEX is not case-sensitive.  But we need to understand that there are few methods in apex, which takes the case-type (lower/upper) into consideration.   When you use the method 'equals' it will return TRUE only if the LHS and RHS are of same value and same case-type. Look at the below example

If you still want to make use of "equals" without taking case-types into consideration you have to either use method "equalsIgnoreCase()" (or) convert both the LHS and RHS into either lower / upper case and then do the comparison, but remember that these methods wont work for "null" values.   Whereas, operator '==' does the job without any such case conversions.  Use method 'equals' to do a comparison only when you want the case-match to be taken into consideration.

2. Concatenation of Strings

If given a requirement to concatenate two strings, we all tend to use the operator '+', but what if I tell you that the method .join() consumes way lesser time than the operator '+'.. Let me elaborate by taking an example.  I am trying to prepare a String by adding all the names of Opportunities separated by a comma.  There are 8500 records present while executing the below logic.

Above code consumed CPU Time of 1049ms.  Now let me execute the same logic by getting rid off the '+' operator by using "join" instead.

Above code consumed CPU Time of just 586ms which is almost 50% lesser than the time taken by the "+" operator.  Also as you are creating a new collection variable, ensure to take the heap size to take into consideration.  You can do the above implementation in your own orgs to get the results.

3. Avoid un-necessary creation of collection variables while preparing Map

Let us take a scenario of preparing Map<Id, list<Opportunity>> where key is AccountId and value will be its associated Opportunities.  Most of us will be writing code like below

In the above logic we have created an extra list at line#6, populated it with the current iterating record and then added it to the map, so that override will happen.  We need to understand that maps are mutable and that gives us the flexibility to modify an element of a map directly without having to add it again.  Consider the logic below

By using the above approach, we completely eliminated the need of creating an extra list and using the same to override the existing value.  

4. Do not use String datatype for holding Id's

I have seen many instances where developers use data-type String to hold value of type "Id". There are many drawbacks of using that approach.  We all know that Id's can be of length 15 or 18 based on the case-sensitivity.  Let us take a simple example to understand the consequence.  I am just hardcoding for our scenario, but keep in thoughts that this is never encouraged as a practice.

Reference : https://salesforce.stackexchange.com/questions/348609/why-this-map-return-null-value/348616

We need to have our code always dynamic in nature.  We can understand from the above example that if we store 15 digit Id in a string, it will fail when used against 18 digit Id and vice-versa.  But if we use the use "Id" data-type rather than string for the above, logic works just smooth.

Hope you find this interesting.  There are still many points to add and few more will be posted soon.   Let me know in the comment section if you have any such tips.  Feedback is much appreciated and thanks for being an awesome reader.  

..Bazingaa..