Google Geocode JavaScript Address Validation

I got a chance to play around with address validation using Google geocode API v3. In my case I use the client side geocoding technique to submit full address (street address + suburb + state + postcode) to find out whether the results returned. The suburb, state and postcode is coming from a proper list.

What I found out with Google geocode is that when you submit full address, it also returns result with partial_match and they don't give an easy filter to exclude these results. Since I will always submit a full string address, I will just get the address when there is no partial_match property in the returned results. So far it works quite well for my situation.


SharePoint 2013 list form headings using JSLink and jQuery

In SharePoint, when you want to modify the list forms, there are couple of ways that you can go about it such as modifying the form or creating custom form using SP Designer or Infopath, or creating custom aspx using Visual Studio.

All those approaches can take a while to implement. With SP2013 with the JSLink functionality, we can quickly inject the headings using jQuery if you just need simple headings or HTML like this:

In this case, I have a solution created in my VS2012 to create the site columns, content type and then the list itself for easy deployment.

I then created a JavaScript file to be deployed to my Style Library (or you can choose other location) that contains the jQuery code:

In the schema.xml of my list, inside the Forms tag you just have to add your JSLink attributes pointing to your jQuery file and the JSLink file:

And there you go :)


CRM 2011 SharePoint 2013 integration ADFS setup for Single Sign On (SSO)

Hi All,

After several hours trying to make this work with the help from technet articles, forums and the help from my colleagues, I managed to get this working. My configuration:

1. CRM 2011 has been configured as IFD using ADFS  (see here)
2. My original site is in Default zone (can be either http/https) with Windows Auth
3. I configured ADFS + map LDAP attributes
4. Web application is extended to other zone (in my case Intranet) to be the ADFS site

The reason we can't have 1 site for both Default and ADFS is because the CRM List component does not like the Sign In page when hitting 'Documents' section inside CRM.

The reason we want Windows Auth as well is to be able to crawl the site as well as for admin purposes.
Go to your ADFS Server, open your ADFS management:

1. Add relying Party Trusts with this configuration
Enter data about the relying party manually, Next
Enter display name, Next
Choose ADFS 2.0 profile , Next
Click enable support for the WS-Federation Passive protocol.  Type in (your going-to-be adfs site url)/_trust/ ,Next
Type in urn:site:sharepoint and click Add, Next
Permit all users to access this relying party, Next

2. In Claim Rule window, click Add Rule (Issuance Transform Rules tab). Rule template: Send LDAP Attributes as Claims, Next
Attribute store: Active Directory
Mapping LDAP Attribute:
sAMAccount Name -> Windows account name
tokenGroups -> Role
userPrincipalName -> UPN
E-Mail-Addresses -> E-mail address

3. In AD FS2.0 -> Service -> Certificates, export the Token-signing certificate (check if there is parent cert or just a single cert as shown in here )

4. Using SharePoint 2013 Management Shell (if there is parent cert need to add parent as well):

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("")
New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert
$signInURL = (your adfs site)/adfs/ls
$realm = “urn:site:sharepoint”
$samClaimMap = New-SPClaimTypeMapping -IncomingClaimType "" -IncomingClaimTypeDisplayName "Login" –SameAsIncoming

$upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "" -IncomingClaimTypeDisplayName "UPN" –SameAsIncoming

$roleClaimMap = New-SPClaimTypeMapping -IncomingClaimType "" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming

$sidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "" -IncomingClaimTypeDisplayName "SID" –SameAsIncoming

$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS Provider" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings  $samClaimMap, $roleClaimMap, $upnClaimMap, $sidClaimMap -SignInUrl $signInURL -IdentifierClaim $ samClaimMap.InputClaimType



Go to central admin -> Manage Web Applications. Select your default site and Extend web application with following config:
Port 443
Enable SSL
Windows Auth NTLM and Trusted Provider ADFS both enabled
Zone - Intranet

After creation, configure your SSL certificate, then log in to your ADFS site using your Windows account to add your ADFS users (in this case the Windows account name without the domain since we are using SAMAccountName identifier claim)

Then go back to your Intranet authentication provider to turn off Windows Auth.
From this point, when you go into CRM and access 'Documents' section, ADFS should recognise your token and let you in straightaway.


When you create your search service application, set your content source to be the Default zone site and it should be working nicely.


SharePoint Event Receiver ItemAdded assign permission


Sometimes we want to remove permissions and only assign permission to the user who uploaded the document in the document library.

Here is the snippet:


SharePoint Copy permission, create group and assign permission to document library or list programmatically

This is an example to do stuff as written in the post title :)


SharePoint Add Datasheet View Programmatically


Just a quick function to add Datasheet View when you're creating a document library or list programmatically: