Formatting and Localizing dates in javascript in Lightning

Date formatting in javascript

AuraLocalizationService JavaScript API provides methods for localizing dates and formatting.

Use the formatDate() to format date by providing format string as second argument.

formatDate (String | Number | Date date, String formatString)

Use $A.localizationService to use the methods in AuraLocalizationService.

Below are few examples of format string and their output:

var now = new Date();
var dateString = "2017-12-12";

// Returns date in the format "Dec 12, 2017"
console.log($A.localizationService.formatDate(dateString));

// Returns date in the format "2017 12 12"
console.log($A.localizationService.formatDate(dateString, "YYYY MM DD"));

// Returns date in the format "December 12 2017, 11:03:47 PM"
console.log($A.localizationService.formatDate(now, "MMMM DD YYYY, hh:mm:ss a"));

// Returns date in the format "Dec 12 2017, 11:03:57 PM"
console.log($A.localizationService.formatDate(now, "MMM DD YYYY, hh:mm:ss a"));

Refer below link for more details:
tokens supported in format string

Localization

Lightning framework provides client-side localization support on input/output elements. This helps in customize the date and time format.

For example, below code will display date in Europe/Berlin timezone (Dec 13, 2017 2:17:08 AM)

<aura:component>
    <ui:outputDateTime value="2017-12-13T02:17:08.997Z"  timezone="Europe/Berlin" />
</aura:component>

To customize date and time format use, lightning:formattedDateTime.

The attributes on lightning:formattedDateTime helps you to control formatting at a granular level. For example, you need to display the date using the MM/DD/YYYY format, then use below code:

<lightning:formattedDateTime value="{!v.datetimeValue}" timeZone="Europe/Berlin" year="numeric" month="numeric" day="numeric"/>

datetimeValue can be set in controller code either in doInit or any other function as mentioned below:

var date = new Date();

component.set("v.datetimeValue", date)

Locale Information on client side controller

• $A.get("$Locale.timezone")  : This will return timezone like Europe/Paris, Europe/Berlin etc.
• $A.get("$Locale.currency") : This will return org currency locale like "$", "¥" etc.

Hope this will help!!!!

Access Grants : Record Access Calculation in Salesforce

Salesforce always check record accessibility whenever user view record in order to maintain data visibility as per sharing settings specified in org. Record access can be granted based on role hierarchy, sharing rules, in-built sharing etc.

Imagine a large scale implementation which involve large number of roles, sharing rules and customized apex managed sharing. In order to determine user access for record by considering  this scenario will take lot of time and will result in performance issue.

In order to avoid this kind of performance issues, Salesforce doesn't calculate record access in real time but it calculate record access whenever any configuration change occurs and store that information. This helps in calculating the record access in real time instead of traversing all hierarchies, applying all sharing rules or analyzing other available record sharing mechanism.

Access Grants

Salesforce uses Access Grants in order to identify how much access user have to object records. This comes into picture only when OWD for object is either PRIVATE or PUBLIC READ ONLY.
Access Grant also specify the sharing tool (like sharing rule, teams,roles etc) responsible for providing record access to user.

There are four types of access grants used by Salesforce:

• Explicit Grants

Salesforce uses explicit grants when records are shared directly to user or groups. Below are few scenarios which are considered under this:

1.  Teams : When user is part of account, sales or case team.
2. When user or queue becomes record owner. All users under that queue get access to record.
3. When record is shared by using sharing rule, apex manage sharing and manual sharing.
4. When record is shared with user or queue based on assignment rule or territory rules share record with territory. All users under that territory get access to record.

Note: If you are using Enterprise Territory management, user can not share record manually to territory and while using sharing rules or apex managed sharing, record can not be shared with territory groups.

• Implicit Grants

This is called as built-in sharing in salesforce. These are predefined record sharing behavior for  Sales, Service and portal applications. For example:

1. User can view parent account record if they have access to child opportunity, case or contact record.
2. If user has access to parent account, then they can access child opportunities, cases and contact records.

• Group Membership Grants

This grant comes into picture when user, personal or public group, queue, role or territory is a member of group that has explicit access to record. So it means all user users or group which are part of public group with which any record is shared, the all group members and members present in sub-group  will get access to records.

• Inherited Grants

This comes into picture when user get access to records because of role hierarchy, territory hierarchy or inherit access through group hierarchy.

Sharing database Architecture

Salesforce store access grants in three types of tables:

• Object Record Tables

This table indicate which user, group or queue own each record.

• Object Sharing Tables

This table store information like which record is shared with which user or group either by apex manage sharing rule or declarative sharing when object OWD is not PUBLIC READ/WRITE.

This table store data that supports explicit and implicit grants.

• Group Maintenance Tables

This table store data that supports group membership grants and inherited grants. 

Declarative Sharing Vs Apex Managed Sharing

Force.com platform provides declarative sharing option which are easy to configure and meets basic data sharing requirements.

Different declarative sharing options

• Record Ownership

Record owner will have read, edit, delete, share and transfer access.

• Teams

Account teams, sales team and case team allow group of users to have access to different account, opportunities and case records.

• Role hierarchy

This allow users in higher role to have same level of access to data which users have in lower hierarchy.

• Sharing rules

You can create owner based or criteria based sharing rules in system which will open up the record access to users. Records can be shared to public group, roles,roles and internal subordinates, roles internal and portal subordinates etc.

Sharing rules also allow to share data with external users. The default external access level must be more restrictive or equal to default internal access level.

For example, if external sharing default is set to Public Read-Only for custom object, then valid internal default settings will be Private and Public Read Only.

• Manual Sharing

Manual Sharing is also known as User Managed Sharing. This option allow user to share record manually with another user or public group, portal roles, portal users, roles, roles and internal subordinates, roles internal and portal subordinates etc.

Remember if record owner share record manually with another user and later on record owner changes, then manual sharing record will be deleted.

Apex Managed Sharing

This allows developers to share records by using apex code. This is also known as "Programmatic Sharing". Object share records can be created for standard and custom object but custom sharing reason can be defined for custom object only.

For example, if we have to share a record with a user specified in lookup field, then you can use trigger to create record in share table to provide access. 

Valid access level for records are Edit/ Read.

If OWD for object is either Public Read only or Private, then share table will exist for that object. You can create record in that share table to provide access to any user. Below are 4 fields you need to specify in order to create record in share table:

• ParentId : 15 digit or 18 digit id of record which you want to share.
• UserOrGreoupId : User id or group Id
• Access Level : Edit or Read. This field must be set to an access level that is higher than the organization’s default access level for the parent object.
• RowCause : You can specify the reason for sharing record. First define sharing reason for custom object. For standard object, you can specify Manual.

 You can not update ParentId field.

You can share record with same user or group by using different sharing reasons.

Consideration while using Apex Managed Sharing

• If record owner changes, then sharing created through apex managed sharing (if row cause is not manual and uses custom sharing reasons) are maintained but if user share record manually, then record sharing will be lost if owner changes.
• User with "modify All Data" can only add, edit or delete records in share table.

Change Set Implementation Tips

Change sets allows to deploy metadata between connected orgs. By using this, Admin can create the change sets and add the components to it and can deploy it to next org. It can be used to deploy metadata between sandboxes and from sandbox to production.

Below diagram explain the change set implementation:

 Main challenge with change sets is mentioned below.

• If any error comes while validation using change sets then it stops validating other components. So we have fix the error and then again needs to validate it. But if we migrate metadata using ANT, then we get all deployment errors which help us to fix all errors in one shot.
• Deployment process using change sets becomes complex if it involves large number of different metadata.

Solution

If we split the change set into different change set, then it will make job easier. You can split components in different change set and deploy it in order mentioned below:

• First Change set

• Static Resource
• Custom Data Types
• Custom Fields
• Custom Labels
• Custom Objects
• Folders
• Record Types
• Validation Rules
• Custom Settings
• Field Sets
• Remote Sites
• Documents

• Second Change set

• Custom Report Types
• List Views
• Apex Classes
• Apex Sharing Reasons
• Apex Triggers
• VisualForce Components
• VisualForce Pages
• Email Templates
• S-Controls
• Letterheads
• Aura Components

• Third Change set

• Reports
• Dashboards

• Fourth Change set

• Page Layouts
• Buttons
• Links
• Homepage Components
• Homepage Layouts

• Fifth Change set

• Workflow Email Alerts
• Workflow Field Updates
• Workflow outbound Messages
• Workflow Rules
• Workflow Tasks

• Sixth Change set

• Apps
• Tabs
• Analytic Snapshots
• Language Translations

Hope this will help!!

Lightning Tree : Generic Lightning Component to Display Hierarchy for any sObject

In API version 41.0, Salesforce has introduce new component called lightning:tree. This can be used to display hierarchy in tree structure. Before this, we have to used jquery or other javascript libraries to implement this.

After introduction of lightning:tree, it is very easy to use this and implement this in short time.

I have created a generic lightning component to display records hierarchy in tree structure. You just have specify below attributes to component to display tree structure:

• ltngcurrentRecId : Salesforce 15 or 18 digit Id of any record for which you want to see hierarchy.
• ltngSobjectname : sObject API name (like Account, Case, Position__c etc.)
• ltngParentFieldAPIName : Field API name which creates self relationship between records.
• ltngLabelFieldAPIName : Field API name which will be used to display records in tree structure(like Name, CaseNumber, Title__c etc.).
• ltngHierarchyHeader : Header label which will be displayed above tree structure.

Below is complete complete code for your reference:

You can use this code as reference and can implement different logic.

Hope this will help!!!

Looking forward for everyone's comments and suggestions.

How to fix error while deploying new custom objects along with list views to new Org

Below are the two different errors we got when we deploy new custom object along with list view to new org through single single package:

• Error: This View Unique Name already exists or has been previously used. Please choose a different name

First error happens if you have list view on object which is shared with all internal users. If you remove below tags from exported metadata of list view, then you will not get this error.

<sharedTo>

        <allInternalUsers></allInternalUsers>

</sharedTo>

After removing these tags, I was able to deploy successfully.

• Added entity: New_Object__c support on queue: New_Queue

This error happens because your list view refers to queue and same queue refer to same object.

Resolutions:

• Split your package for deployment because there is dependency between object, list view and queues. Deploy these three things separately. 
• First deploy custom object with basic information. Remove list views tags from .object file before deployment.

Best Solution:

Create custom object manually in target org and deploy the package. This is best approach as you don't have to change any metadata files.

Recommendation:

Deployment errors also come if you deploy approval process which contains approver as queue and those quesues refer to same object on which you have approval process. So always first create custom object in target org and then deploy queues and then deploy remaining things.

Hope this will help!!!

Webinar : Build Smarter Apps with Einstein Platform Services

This webinar was held on 28th September, 2017.  Below are the list of speakers for this webinar:

• SHANE MCLAUGHLIN (Principal Demo Engineer,Salesforce)
• KATIE HURLEY (Senior Manager, Product Marketing Salesforce)
• KRIS CHANT (Director, Developer Marketing Salesforce)
• MICHAEL MACHADO (Director, Product Management Salesforce)

This webinar helps in understanding Einstein Platform Services. This is intended for Administrators and developers. If you missed this webinar then, you can refer below webinar recordings and slides.

Webinar Recording:

Webinar Slides: 

Build Smarter Apps with Einstein Platform Services from Salesforce Developers

Hope this will help!!!