Iterative Logic

Development and User Experience Blog

Salesforce Known Issues List now Available!

link: http://success.salesforce.com/issues_index

For some time now I have wanted Salesforce to publish a list of known issues for the platform. After all, why spend hours trying to troubleshoot an issue that has already been found and is actively being worked on. Also, on the flip side it gives the community a better chance at supporting itself because we can work on solutions and workarounds to an issue rather than simply trying to go back and forth and confirm it’s a bug – which in my opinion enables Salesforce to continue to allow the community to primarily support itself when it comes to custom development.

So I thought I would take a moment to go through a bit of a Q&A on the topic:
View more

Leave a Comment

A little speculation about Salesforce Touch

With the coming release of Salesforce Touch, which I predict will be released either at or just after Dreamforce 2012, I wanted to explore what impact this will have for developers and the platform itself.
View more

Leave a Comment

How to tell if a user has access to a record

This is actually a very exciting topic for me as I have always struggled with ways to secure the customizations I provided to users using Visualforce based on their access to data in the system. So let me first provide some background on when this issue comes up and then we can talk about the latest addition to Salesforce.com as of Spring ’11 (version 24.0) that makes solving for this trivial.
View more

1 Comment

Create your own History Related List in Visualforce

The story starts with getting a requirement to customize the detail view of an existing page. Nothing really extreme just need to be able to display a few sections dynamically based on information on the record etc (and record types was not an option). It’s not the most ideal scenario since overriding a detail view with a custom Visualforce page costs you the ability to control the layout and security with page layouts and record types. Anyway, I made my case and despite my the drawbacks the go-ahead is given to custom build the page as it would result in a better experience for the user.

At first things are going good and the work is progressing as expected. Then my attention turns to adding the related lists to the page and I found that customizing the detail view just cost me a lot more than just customizing the page layout.

Over the last few years Salesforce has sprinkled a lot of little nice usability features to detail pages such as pop-up hover links, chatter, and inline-editing. All of those were challenges that I was prepared to address either by excluding them completely or replicating the functionality.

However, the one thing I didn’t expect to have to replicate was the History Related list for an object. You would think you would be able to add an <apex:relatedlist> tag and set the list attribute to the name of the history list. I tried every name under the sun and then searched the developer forums to find that I wasn’t the only one trying to do this and the overwhelming answer is that it isn’t supported…currently.

For some reason I wasn’t willing to lose this battle. It was one more thing I had to leave out my interface – one more thing I had to explain to the business was not possible “given platform limitations”. I just couldn’t give up that easy. So I decided to replicate the functionality and build my own History Related list. It wasn’t as simple as I thought, so in this article I will describe the features that need to be replicated and share the code that I ultimately ended up with.

View more

Tagged: Leave a Comment

Bug: StandardController addFields Method

I recently came upon a bug when attempting to implement the new addFields method on an Apex Standard Controller class. The purpose of the add fields method is to allow a developer to specify fields that the standard controller should query along with the fields that are defined in the markup of a Visualforce page. This is very useful when you need to evaluate some fields but don’t need to display them.

Prior to this feature you had a couple of options to get the additonal fields you needed:

  • Add the fields to your Visualforce page as hidden input fields
  • Perform a query in the constructor to get the fields you need

Both of the solutions identified above are not ideal. The first option requires you to muddy up your markup with additional fields and creates a bit of a security issue if the data should not be seen by users or anyone for that matter who can right click on the page and click “view source”.

The second option is much more secure but is inefficient as it requires a query call just to get a couple of extra fields. However, in all fairness, in the context of performance it’s not really an issue as the query is pretty fast. But just knowing that my code is performing an extra query when the information could/should be readily available in the StandardController was one of those little things that bugged me but I didn’t have the time to really care about.

Thankfully, the Salesforce developers added a feature to solve for this scenario by adding a method called addFields to the StandardController class that allows the developer to supply a list of fields that the controller should query for in addition to the fields defined in the Visualforce markup.

Seeing the benefits this feature offers I started implementing it and everything worked great! I added the fields to the controller and wrote my controller logic to consume the fields, tested it a few times through the interface and was happy with the performance and how clean my markup and code was. But then everything kind of came to a halt when I began to write my unit tests.

When I ran my test I got the following error message:

You cannot call addFields after you’ve already loaded the data. This must be the first thing in your constructor

The error message above usually occurs if you attempt to use the add fields method more than once but no where in my code was I calling this method more than once. After some trial and error to see if I had done something wrong I contacted Salesforce support and they were able to replicate the results for my particular instance and have leaned towards it being a bug but at this point I do not know if it is a known issue with a patch on the way or something that is just coming up.

The current status of this issue is that it is being researched as a possible bug. In the meantime, I have worked around the issue by querying for the fields I needed so that my code and unit tests can successfully run.

For now the wait is on and I will post an update once I get a response back from Salesforce support.

Tagged: 2 Comments