Select All Checkbox Using Javascript in Visualforce Page

Controller:

public with sharing class Sample { 

    public List<AccountWrapper> accountWrapperList {get; set;}
    
    public Sample (){
        if(accountWrapperList == null) {
            accountWrapperList = new List<AccountWrapper>();
            for(Account a: [SELECT Id, Name From Account Limit 10]) {
                accountWrapperList.add(new AccountWrapper(a));
            }
        }
    }
     
    public class AccountWrapper {
        public Account acc {get; set;}
        public Boolean isSelected{get; set;}
 
        public AccountWrapper(Account a) {
            acc = a;
            isSelected = false;
        }
    }  
    
}

Visualforce Page:

<apex:page controller="Sample" sidebar="false" showHeader="false">
    <script type="text/javascript">
        function selectAllCheckboxes(obj,InputID){
            var inputCheckBox = document.getElementsByTagName("input");    
            for(var i=0; i<inputCheckBox.length; i++){          
                if(inputCheckBox[i].id.indexOf(InputID)!=-1){                                     
                    inputCheckBox[i].checked = obj.checked;
                }
            }
        }
    </script>
    <apex:form >
        <apex:pageBlock >
            <apex:pageBlockTable value="{!accountWrapperList}" var="a" id="table" title="All Accounts">
                <apex:column >
                    <apex:facet name="header">
                        <apex:inputCheckbox onclick="selectAllCheckboxes(this,'inputId')"/>
                    </apex:facet>
                    <apex:inputCheckbox value="{!a.isSelected}" id="inputId"/>
                </apex:column>
                <apex:column value="{!a.acc.Name}" />
            </apex:pageBlockTable>
        </apex:pageBlock>
    </apex:form>
</apex:page>

Output:

TestVisible annotation in Salesforce

TestVisible annotation allow test methods to access private or protected members of another class outside the test class. These members include methods, member variables, and inner classes. This annotation enables a more permissive access level for running tests only. This annotation doesn’t change the visibility of members if accessed by non-test classes.

With this annotation, you don’t have to change the access modifiers of your methods and member variables to public if you want to access them in a test method. For example, if a private member variable isn’t supposed to be exposed to external classes but it should be accessible by a test method, you can add the TestVisible annotation to the variable definition.

This example shows how to annotate a private class member variable and private method with TestVisible and how to access it in test class.

Sample Class:

public class TestVisibleExample {
    //Private member variable
    @TestVisible private static Integer recordNumber = 1;

    //Private method
    @TestVisible private static void updateRecord(String name) {
        // Do something
    }
}    

Test Class:

@isTest
private class TestVisibleExampleTest {
    @isTest static void test1() {
        // Access private variable annotated with TestVisible
        Integer i = TestVisibleExample.recordNumber;
        System.assertEquals(1, i);

        // Access private method annotated with TestVisible
        TestVisibleExample.updateRecord('RecordName');
        // Perform some verification
    }
}

Junction Object in Salesforce

A custom object with two master-detail relationships is called Junction Object. Junction objects are used to create many to many relationships between objects. A many-to-many relationship allows each record of one object to be linked to multiple records from another object and vice versa. One Object can have only two Master-Detail relationships.

For example, Let us assume that we have two custom objects – A and B. To provide the many to many relationship between A and B, we will need to create one more object let’s say it would be C, it will be called as junction object.

The first master-detail relationship you create on your junction object becomes the primary relationship. This affects the following for the junction object records:

Look and feel: The junction object’s detail and edit pages use the color and any associated icon of the primary master object.

Record ownership: The junction object records inherit the value of the Owner field from their associated primary master record. Because objects on the detail side of a relationship do not have a visible Owner field, this is only relevant if you later delete both master-detail relationships on your junction object.

Division: If your organization uses divisions to segment data, the junction object records inherit their division from their associated primary master record. Similar to the record ownership, this is only relevant if you later delete both master-detail relationships.

Note:

  • If we delete record A (First Master detail relationship is always primary) – then child record c will be deleted.
  • If we delete record B then in this case also child record C will be deleted.
  • If we delete record C then only C will be deleted , master record will not be deleted.
  • If child C has two Master record A and B, Where A is primary relation then Child record C will inherit the look and feel of Parent object A.

Visualforce Remote Objects

  • Visualforce Remote Objects are proxy objects that allow basic DML operations on sObjects directly from JavaScript.
  • Remote Objects take some of the complexity out of JavaScript remoting, by reducing the need for @RemoteAction methods in an Apex controller or extension.
  • The Remote Objects controller handles sharing rules, field level security, and other data accessibility concerns. Pages that use Remote Objects are subject to all the standard Visualforce limits.
  • Like JavaScript remoting, Remote Objects calls don’t count towards API request limits.
  • Perform actions like Retrieve, Create, Update, Upsert, Delete with Remote Objects.
  • Visualforce Remote Objects is an effective tool for quickly adding simple data operations to Visualforce pages.

Using Visualforce Remote Objects:
Using Visualforce Remote Objects consists of two parts:

  • Access definitions, written in Visualforce using the new Remote Objects components. These components generate a set of JavaScript proxy objects that you can use in the next step.
  • Data access functions, written in JavaScript. These functions use the proxy objects made available by the access definitions to perform create, select, update, and delete operations on your data.

Your page then uses the data access functions to respond to user interaction, including form submissions or controls changes, or in response to timers, or pretty much anything you can write in JavaScript. Although Remote Objects supports only create, select, update, and delete operations, it’s quite flexible in how it does so.

Visualforce Tags:

apex:remoteObjects : Use this component, along with child apex:remoteObjectModel and apex:remoteObjectField components, to specify the sObjects and fields to access using Visualforce Remote Objects. These components generate models in JavaScript that you can use for basic create, select, update, and delete operations in your client-side JavaScript code.

apex:remoteObjectModel : Defines an sObject and its fields to make accessible using Visualforce Remote Objects. This definition can include a shorthand name for the object, which you can use in JavaScript instead of the full API name. This is especially useful if your organization has a namespace or if you’re packaging an app, and makes your code more maintainable.

apex:remoteObjectField : Defines the fields to load for an sObject. Fields defined using this component, instead of the fields attribute of apex:remoteObjectModel, can have a shorthand name, which allows the use of a “nickname” for the field in client-side JavaScript code, instead of the full API name. Use as child of apex:remoteObjectModel.

Here is an example to Create a Contact Using Visualforce Remote Objects:

Visualforce Page:

<apex:page >
    <!-- Remote Objects definition to set accessible sObjects and fields -->
    <apex:remoteObjects jsNamespace="RemoteObjectModel">
        <apex:remoteObjectModel name="Contact" fields="Id,FirstName,LastName,Phone">
        </apex:remoteObjectModel>
    </apex:remoteObjects>
    
    
    First Name : <input type="text" name="fname" id="fname"/><br/><br/>
    Last Name : <input type="text" name="lname" id="lname"/><br/><br/>
    Phone : <input type="text" name="phn" id="phn"/><br/><br/>
    <p>
        <button class="btn" onclick="create()">
            Create Contact
        </button>
    </p>
    
    <script>
    function create(){
        var ct = new RemoteObjectModel.Contact({
            FirstName: document.getElementById("fname").value,
            LastName: document.getElementById("lname").value,
            Phone: document.getElementById("phn").value
        });
        ct.create(createCallback);
    }
    function createCallback(err, ids){
        if (err) {
            displayError(err);
        }
        else{
            alert("Successfully Created Record with Id :"+ ids);
            document.getElementById("fname").value="";
            document.getElementById("lname").value="";
            document.getElementById("phn").value = "";
        }
    }
    </script>
</apex:page>

Best Practices for Using Remote Objects :
Visualforce Remote Objects is an effective tool for quickly adding simple data operations to Visualforce pages. Remote Objects isn’t always the right tool for the job, though, so it’s important to understand how Remote Objects works and when to use a different tool, such as JavaScript remoting.

  • Field Level Security.
  • Transaction Boundaries.
  • Appropriate Placement and Testing of Business Logic.
  • Handling Complexity.
  • Alternatives to Remote Objects.

Think carefully about what your page or application needs to do, and then choose the right tool for the job. Sometimes that tool isRemote Objects, and sometimes it’s something else.

Advantages of Using Remote Objects :

  • No need to write Apex Controller.
  • No need for @RemoteAction methods(@RemoteAction annotated methods needs to be static so you had to take special precaution as it didn’t supported View state. This hurdle is completely removed now.)
  • Do not Consume Orgs daily API limits.
  • No need of test classes.
  • Light way to perform rapid client side querying.

Salesforce Apex Sharing Reason

Apex sharing reason is used to identify, why the record are shared with the user. If a developer is doing any operation on that record sharing then he can able to identify, in which sharing records he needs to do the operation. Its especially for managing a record sharing through apex code. We can share a record multiple times with the same user or group using different Apex sharing reasons.

Lets go through this with below example.

Here I’ve a custom object “Bank” and the OWD of this object is set as “private” under the “Security control” for users.

If an object OWD is set as “private”, then user have access to the object records which is created by himself. Once you made this change “Sharing” button will be added into the “Bank” page layout. By using this Sharing button you can able to view the record access which means who have access to that records.

But here I will explain you how to extend the records access(Sharing the record) to users or group through apex code.

Here for “Bank” custom object the OWD is set as “private” under the “Security control” for users.

In “Bank” custom object in Apex Sharing Reason related list, I’ve created an Apex Sharing Reason as “Account Manager”.

In my org I have a user called Abhijeet. He is the Account Manager. If any Bank record is created by an user then that record should shared using apex with the Account Manager Abhijeet. Suppose Biswajeet is creating a Bank record called “State Bank of India” then that record should be shared with Abhijeet.

Here is the “State Bank of India” record, and record owner is Biswajeet.

Using below apex code we can share this record with Abhijeet. In below apex code “UserOrGroupId” is Abhijeet UserId and “ParentId” is “State Bank of India” record Id.

Bank__Share objBank = new Bank__Share();
objBank.AccessLevel = 'Edit'; //Access Level
objBank.UserOrGroupId = '00590000002Qi1f';//UserId or Public Group Id
objBank.ParentID = 'a0B9000000yNgXo';//Object Record Id
objBank.RowCause = Schema.Bank__Share.RowCause.Account_Manager__c;//Record Sharing Reason
Insert objBank;

Salesforce displays Apex sharing reasons in the Reason column when viewing the sharing for a custom object record in the user interface. This allows users and administrators to understand the purpose of the sharing. After executing above apex code the output will look like below snap.

Note:

  • Only users with the “Modify All Data” permission can add, edit, or delete sharing that uses an Apex sharing reason.
  • Deleting an Apex sharing reason will delete all sharing on the object that uses the reason.
  • You can create up to 10 Apex sharing reasons per custom object.
  • You can create Apex sharing reasons using the Metadata API.