Javascript Accessor Properties

There are two different types of properties: data properties and accessor properties.

• Data properties contain a value.
• Accessor properties don’t contain a value but instead define a getter function and a setter function.

const person1 = {
   _name: "Nicholas",

   get name() {
      console.log("Reading name");
      return this._name;
   },

   set name(value) {
      console.log("Setting name to %s", value);
      this._name = value;
   }
};

console.log(person1.name);   // "Reading name" then "Nicholas"

person1.name = "Greg";
console.log(person1.name);   // "Setting name to Greg" then "Greg"

This example defines an accessor property called name. There is a data property called _name that contains the actual value for the property.

The leading underscore is a common convention to indicate that the property is considered to be private, though in reality it is still public. The syntax used to define the getter and setter for name looks a lot like a function but without the function keyword. The special keywords get and set are used before the accessor property name, followed by parentheses and a function body.

Javascript Object properties

Detecting Properties

The in operator looks for a property with a given name in a specific object and returns true if it finds it.

console.log("name" in person1);   // true
console.log("age" in person1);    // true
console.log("title" in person1);  // false

Keep in mind that methods are just properties that reference functions, so you can check for the existence of a method in the same way.

const person1 = {
   name: "Nicholas",
   sayName: function() {
      console.log(this.name);
   }
};

console.log("sayName" in person1);  // true

In some cases, however, you might want to check for the existence of a property only if it is an own property. The in operator checks for both own properties and prototype properties, so you’ll need to take a different approach. Enter the hasOwnProperty() method, which is present on all objects and returns true only if the given property exists and is an own property.

const person1 = {
   name: "Nicholas",
   sayName: function() {
      console.log(this.name);
   }
};

console.log("name" in person1);                         // true
console.log(person1.hasOwnProperty("name"));            // true

console.log("toString" in person1);                     // true
console.log(person1.hasOwnProperty("toString"));        // false

Removing Properties

You need to use the delete operator to completely remove a property from an object.

const person1 = {
   name: "Nicholas"
};

console.log("name" in person1);  // true

delete person1.name;             // true - not output
console.log("name" in person1);  // false
console.log(person1.name);       // undefined

Enumeration

By default, all properties that you add to an object are enumerable, which means that you can iterate over them using a for-in loop. This example uses bracket notation to retrieve the value of the object property and output it to the console, which is one of the primary use cases for bracket notation in JavaScript.

var property;

for (property in object) {
   console.log("Name: " + property);
   console.log("Value: " + object[property]);
}

If you just need a list of an object’s properties, use Object.keys() method to retrieve an array of enumerable property names. Typically, you would use Object.keys() in situations where you want to operate on an array of property names and for-in when you don’t need an array.

var properties = Object.keys(object);

// if you want to mimic for-in behavior
var i, len;

for (i=0, len=properties.length; i < len; i++){
   console.log("Name: " + properties[i]);
   console.log("Value: " + object[properties[i]]);
}

Keep in mind that not all properties are enumerable. You can check whether a property is enumerable by using the propertyIsEnumerable() method, which is present on every object:

var person1 = {
   name: "Nicholas"
};

console.log("name" in person1);    // true
console.log(person1.propertyIsEnumerable("name"));  // true

var properties = Object.keys(person1);

console.log("length" in properties);    // true
console.log(properties.propertyIsEnumerable("length")); // false

How to access map value in lightning component

Scenario: I have to create a picklist in Lightning, the values of which will be fetched from an already defined custom setting. The Apex method will be returning a map of values.

Define a method in Apex class SampleController which will return a map of values.

@AuraEnabled
public static Map<String, String> getselectOptions() {
    Map<String, CustomSettingName__c> values = CustomSettingName__c.getAll();
    Map<String, String> options = new Map<String, String>();
    
    for (String key: values.keyset()) {
        options.put(key, values.get(key).CustomSetting_Column__c);
    }
    return options;
}

Now in client side controller, create a new array optionsList. Add the values to this new array from the response object returned.

var optionsList = [];
for (var key in response) {
    if (response.hasOwnProperty(key)) {
        optionsList.push({value: key, label: response[key]});
    }
};
component.set('v.optionsList', optionsList);

Once the array is populated with the values, using aura:iteration tag populate the picklist values as below:

<aura:component controller="SampleController">
    
    <aura:attribute name="optionsList" type="List"/>

    <lightning:select name="selectItem" label="text" onchange="{!c.checkOptionValue}" value="{!v.partnerTypeSelected}" >
        <aura:iteration items="{!v.optionsList}" var="option">
            <option value="{!option.value}" text="{!option.label}" 
                    selected="{!option.selected}">
            </option>
        </aura:iteration>
    </lightning:select>
    
</aura:component>

Salesforce Security: Concepts

Salesforce Security Layers

1. Organization: Login IP ranges, Login hours; when where how can a user login to the org
2. Object: Object-level security; what action can a user have on a specific object
3. Field: Field-level security; what field can a user read/edit
4. Record: Sharing; what records can a user access

From an architect’s perspective, data access in Salesforce falls into 2 main categories:

• Object-level access, which includes field-level access
• Record-level access

Profiles and Permission Sets determine the object level security access to each object in Salesforce.

Read object-level security doesn't give Read access to all account records, it only gives the ability to read account records.

Profiles

A profile contains the baseline permissions of a user, and each user is assigned only 1 profile. It defines a user’s ability to peform different functions, access records, and the way the records are displayed. Profiles are tied to a user license.

Enhanced profile user interface lets you search for any setting and it can take you to this setting page. This can be set up in Setup —> User Management Settings.

Permission Set

A permission set is a collection of permissions that can be assigned to a user extending users’ functional access without changing their profiles. Users can have only one profile but they can have multiple permission sets.

Permission Set Group (PSG): It is a collection of permission sets. Users with a PSG receive the combined permissions of all the permission sets in the group. You can also remove individual permissions from a group with the muting feature, to further customize the group. Please note that a PSG can only contain 1 muting permission set that is created within the group.

A profile doesn’t provide the appropriate mechanism for scalable permission assignment. Permission sets and PSG are used to avoid the creation of many different profiles that are only slightly different.

List of permissions that are missing in a permission set

• Page layout assignment
• Login hours and Login IP ranges
• Desktop client access
• Session settings
• Password policies
• Delegated Authentication
• 2-factor authentication with SSO
• Organization-wide email addresses are assignable by profiles only
• Default record type per object
• Profile specific search layouts

Record Ownership

Every record must be owned by a single user or queue. The owner has access to the record, based on the object settings of the owner’s profile. Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue.

Record ownership and full access are synonymous and interchangeable and provide the user with the highest level of access to a record.

Sharing (record-level access)

Record-level access determines which records a user can see for a specific object. Object-level security should allow to access this record.

• Organization-Wide Defaults
• Role Hierarchy
• Sharing Rules
• Manual Sharing
• Team Sharing
• Territory Hierarchy Access

For each object, the View All and Modify All permissions ignore sharing rules and settings.

View All Data and Modify All Data administrative permissions apply to all objects’ records.

Organization-wide Defaults (OWD)

OWD sharing settings specify the default level of access users have to each others’ records. OWD are the only way to restrict record access. You use OWD settings to lock down your data to the most restrictive level, and then use other sharing tools to selectively give access to other users. For each object, the OWD can be:

• Private
• Public read only
• Public read/write
• Public read/write/transfer: available for cases and leads
• Public full access: available for campaigns
• Controlled by parent

Role Hierarchy

Users can access the data of all the users directly below them in the hierarchy (subordinates) using the Grant Access Using Hierachies option. Managers gain as much access as their subordinates. This access applies to records owned by users, as well as records shared with them.

Public Group

A public group is a collection of individual users, roles, territories, and so on, that all have a function in common.

Groups can be nested (group A nested into group B), but keep in mind that nesting has an impact on group maintenance and performance due to group membership calculation. Don’t nest more than 5 levels. As a best practice, keep the total number of public groups for an organization to 100,000.

Sharing Rules

They allow for exceptions to OWD settings and the role hierarchy that give additional users access to records they don’t own. There are 2 types of sharing rules:

1. Ownership-based: records are shared following criteria based on their owner. For example, share all opportunities owned by user A with Group B. As a best practice, keep the number of ownership-based rules per object to 1000.
2. Criteria-based: they provide access to records based on the record’s field values.

Manual Sharing

Gives user the flexibility to share specific records with users that need to see them. To grant access to a record, you must be one of the following users:

• The record owner
• A user in a role above in the hierarchy
• Any user granted Full Access to the record
• An administrator

Team Sharing

For accounts, opportunities and cases, record owners can use teams to allow other users access to their records. The record owner adds team members and specifies the level of access each team member has to the record, so that some team members can have read-only access and others can have read-write access. The record owner can also specify a role for each team member.

Using Dynamic Apex to retrieve Picklist Values

USECASE: Fetch the picklist values from Industry field of Account sObject.

List<SelectOption> options = new List<SelectOption>();

Schema.DescribeFieldResult fieldResult = Account.Industry.getDescribe();
List<Schema.PicklistEntry> picklistEntries = fieldResult.getPicklistValues();

for (Schema.PicklistEntry picklistEntry : picklistEntries) {
    options.add(new SelectOption(picklistEntry.getLabel(), picklistEntry.getValue()));
}

return options;

OR

List<SelectOption> options = new List<SelectOption>();

Map<String, Schema.SObjectField> fieldMap = Account.getSObjectType().getDescribe().fields.getMap();
List<Schema.PicklistEntry> picklistEntries = fieldMap.get('Industry').getDescribe().getPickListValues();

for (Schema.PicklistEntry picklistEntry : picklistEntries) {
    options.add(new SelectOption(picklistEntry.getLabel(), picklistEntry.getValue()));
}

return options;