Wednesday, December 3, 2014

Where are my Featured Search images in Kokua?

If you're trying out the new Community Designer feature (in beta still, as of Winter '15), you may run into a bit of trouble getting the images to appear correctly for Featured Search on Kokua's homepage. At a high level, there are the three key requirements to getting an images to appear on the homepage, explained in more detail below.

  • Name the image as DataCategoryUniqueName-s.jpg
  • Upload the image as an asset using Site.com Studio
  • Enter a value using merge fields into the Category Image URL: {!Global.PathPrefix}/{!DataCategory.Name}.jpg

Note: The ".jpg" extension is not required, but it must match what you entered for the Category Image URL.

Name the image


To figure out what to name an image for a data category, you need to know the data category's Category Unique Name is. To figure this out, first go to Setup > Customize > Data Categories > Data Category Setup. Next, click the Actions button next to an existing data category, then click Edit Category. Now the Category Unique Name field and value will be exposed.


For the Featured Search box on the homepage, you need to specify 's' (stands for "square") for the <size> portion of the filename. Here are some examples.

Examples of image filenames for Featured Search
Data Category Unique NameImage TypeImage Filename
Technology_EnablementJPEGTechnology_Enablement-s.jpg
Customer_EngagementJPEGCustomer_Engagement-s.jpg
StrategyPNGStrategy.png

Note: The Winter '15 documentation for Featured Search says that you should use the convention <datacategoryname>-<size>.<filetype>. However, a more accurate convention is <datacategoryuniquename>-<size>.<filetype>.

Upload the image


This part is relatively simple. All you need to do is open Site.com Studio for the community's site, and then upload the image as an asset.

  1. Go to Setup > Customize > Communities > All Communities
  2. Click Community Designer next to your community
  3. Click the top header's picklist next the the word "Communities", and click Go to Site.com Studio
  4. In the left-hand navigation tree, click Assets under All Site Content
  5. Click the Import... button, and upload your image


Note: If you upload a .zip file where the images are stored in folders, you will need to tweak your Category Image URL in the last step.

Enter a value for Category Image URL


Finally, while you're in Site.com Studio, you need to edit the main page and enter a value for the Category Image URL property in Featured Search.
  1. On the Overview tab, click Site Pages under All Site Content
  2. Double-click main under Site Map to open the page
  3. In the Views section, double-click Kokua Home to edit the view
  4. Under Page Structure, click Featured Data Categories
  5. In the Property Editor in the right sidebar, enter this exact value for Category Image URL: {!Global.PathPrefix}/{!DataCategory.Name}.jpg


Note: In the previous step if you uploaded a .zip file where the images are stored in folders, you need to include the folder names in the Category Image URL value, such as: {!Global.PathPrefix}/folder/subfolder/{!DataCategory.Name}.jpg

Friday, November 21, 2014

Login with Facebook for a community with Visualforce

Adding an auth provider (e.g., Login with Facebook) to a Salesforce Communities instance is pretty easy.


The Login with ... button is pretty magical: It knows what community you're logging into, and it knows what URL you're trying to access upon authentication. Based on that information when you click the button, you're taken to the correct authentication URL based on the Auth Provider configuration in Salesforce.

But... for orgs that have customized their login pages with Visualforce, how do you add this button? Luckily, adding the same magical button to a custom Visualforce login page doesn't require you to manually reconstruct the OAuth authentication endpoint. Instead, you can just use the AuthConfiguration.getAuthProviderSsoUrl() method.

Simply put, you need just three things:
  • Your community's base URL
  • The relative path after the base URL to which the user should be taken upon successful authentication. This is also known as the startUrl.
  • The URL Suffix (a.k.a. DeveloperName) of your auth provider (e.g., Facebook) as configured in Salesforce

Once you have this information, all you need to do is create an action in your Apex controller that returns a PageReference object, constructed from the URL returned by AuthConfgiuration.getAuthProviderSsoUrl().


This same approach can be applied to other auth providers as well, such as Twitter or Google.

AuthConfiguration.getAuthProviderSsoUrl(String, String, String) explained

Curious about AuthConfiguration.getAuthProviderSsoUrl(String, String, String)? Here are some notes about the parameters that may not be apparent the first time you read the documentation.

String cUrl


You'll want this to match exactly what you see when you're looking at your community's Administration Settings. Don't add any extra trailing slashes!


String startUrl


This should be the URL relative to the value you put for cUrl, including the leading forward-slash ('/'). For example, if you want to land the user at the Home tab, startUrl should be set to "/home/home.jsp" (again, note the inclusion of the leading forward-slash).

Think about it this way: If you concatenate cUrl and startUrl, exactly as written, you should end up with a valid URL to the desired page or resource within your community.

String developerName


This is the DeveloperName field from the AuthProvider object. Or, you can find the value by looking at the URL Suffix field on the Auth Provider detail page.


You can find this value dynamically by querying the AuthProvider object.

Sunday, November 9, 2014

Add, edit and remove parent and child records in Lightning component

After figuring out that I could leverage indexVar and custom data-* attributes to efficiently remove items from a list in Lightning, I decided to see whether the same component pattern could be applied to enable dynamic management of lists at a parent object level and at a child object level.


In the screenshot above (please excuse the ugly styles), the behavior is such that when a user clicks Edit for an account, the list of contacts changes to show only contacts for the selected account.

The basic building blocks of this app are the ns:manageAccounts and ns:manageContacts components, added to the Lightning application as follows:


And within both components, the following pattern is used:


The above concepts are simplified in their illustration, as the full setup also uses several custom events and event handlers. Please take a look at the oneAccount.app repo on GitHub for the full source code behind the sample app.

Lightning really appears to makes dynamic UI updates really simple for the developer, similar to other frameworks like Knockout. The real benefit of Lightning is that it's built directly on top of Salesforce, and as a result makes it easy to leverage the power of Apex in your apps and components.

Friday, October 31, 2014

Simple Lightning-to-Lead tutorial for the Salesforce1 Platform

If you're brand new to Lightning on the Salesforce1 Platform, and you're having a bit of trouble following the cool but relatively complex Expenses sample app from the Lightning Components Developer's Guide, maybe this Lightning-to-Lead tutorial will work better for you.

The goal is simple: Create a one-page app that basically does what Web-to-Lead does, which is to create a new Lead record. Nothing glorious, but it's just complicated enough to go over some core concepts. When you're done, you'll end up with a simple page with a few fields and a lone button.


Sound simple? Give it a try and let me know what you think!

Friday, October 24, 2014

Share Chatter files across communities... or not

"One version of the truth" is the holy grail in content management. Chatter Files is salesforce.com's solution for allowing users to manage document revisions in Salesforce, while making sure that links to the file always give people the latest version. But with Communities, "one version of the truth" becomes more difficult to achieve.

Take the following scenario:
  1. John Doe collaborates with internal users to create a pitch deck for a new product.
  2. John uploads the file to the Competitive Advantage Chatter group in his org's internal community.
  3. Several iterations later, the deck is ready to be shared in his company's partner community, called AllianceNet.
  4. John uses the Global Header to switch from his org's internal community to the AllianceNet community.
  5. John goes to the All AllianceNet group to share the file, already stored in Chatter, with the group, but... where's the file?



As it stands in Winter '15, files created or uploaded to one community, internal or external, can only be shared within that same community in Chatter. So, to share a file across communities, users effectively have to recreate a duplicate instance of the file by uploading it again as a new file to the new community.

The only way that files can be shared or seen across communities is to create a Salesforce CRM Content library that's shared with users who have access to multiple communities. But even then, users will not be able to attach the file to a Chatter post. They'll be able to find the file in Global Search, and share URL links to the file, but unfortunately "native" Chatter file attachments will not be possible.

If this limitation with file sharing across communities affects or bothers you, please promote the idea, "Sharing Files from Chatter to Communities".

Friday, October 10, 2014

Invalid apex:attribute name values

The apex:attribute component in Visualforce allows developers to pass custom Apex class instances as attributes from the parent component or page to the child component. In this manner, it's possible to pass a page controller itself as an attribute to a component on the page, using a simple self property like the following.

public CustomController getSelf() {
    return this;
}

What the documentation doesn't say is that apparently (at least in Winter '15, API 32.0) there are keywords to avoid when naming your attribute, even though the Visualforce parser will not tell you there's a problem.

Trying to name your attribute "controller" will cause something like the following error to appear when saving a page: Wrong type for attribute &lt;c:buggersitepaypalcheckout controller=&quot;{!self}&quot;&gt;. Expected BuggerSiteSimpleSelfRegController, found String



Trying to name your attribute "parent" will cause a completely blank error message to appear when saving a page. But it's an error that will prevent you from saving your page, nonetheless.



Do you know any other hidden no-no's with naming apex:attribute elements? Please share so that we can all avoid these frustrating quirks int he future.