#viewAllDiscoTopics

The topic of this post probably is somewhat out of date, and it is unlikely that you will be encountering this same issue in the future.  However, I do believe it does warrant a post for a number of reasons.  First, because of the ridiculousness of the name and the absurdity of the error, #viewAllDiscoTopics has become something of standing joke for all the idiosyncrasies in Salesforce at my work.  Second, it demonstrates the perils of deploying migration during the Salesforce upgrade period, as I will demonstrate.  And Third and last, it demonstrates the pitfalls of Force.com Migration Tool, something that I will likely return to it over again and again in this blog.

Having outlined what we have learn from this bug, so what is #viewAllDiscoTopics?  Earlier this year,  just about the time when Spring '13 upgrade was being rolled out, we were trying to migrate from a pre-existing dev Sandbox to a newly-created testing Sandbox org using Force.com Migration Tool.  However, when we try to deploy the retrieval into testing Sandbox, we received following, and rather cryptic, error message:

Unknown user permission: ViewAllDiscoTopics

After some Googling, I found out that this was one of the permission that was removed from Spring '13 release of Salesforce.  As both the source and the destination orgs were Sandbox, and appears to have been upgraded, you would expect that either this permission should not have been included when the package was retrieved from the source org or should have been ignored by destination org when we were deploying it.  However, as many of us who have used Force.com Migration Tool know, Force.com Migration Tool is something of all-or-nothing proposition where you have very limited control on what can be retrieved.

Given that one of the reasons Salesforce.com recommends the use of Force.com Migration Tool, one would expect that there must have been some automated process to remove this user permission from retrieved XML metadata file.  Hence, I had opened a case and posted a question on Salesforce.com forum here.  However, only answer I had received was to manually remove that tag from the XML file, as you can see from that discussion.

My Work-around
For our migration process, manually removing this tag every time we migrate just was not acceptable to us.  Hence, I had written a small Python script with xml.etree.ElementTree to automatically remove any occurrence of userPermission tag whose child name node has viewAllDiscoTopics as its inner HTML value.  I won't post the source code here as this is something that is simple to implement and could be implemented with pretty much any modern scripting language.  However, I will post how I have set up my ant script to call to automatically call this removal script after retrieval as I suspect many of us are not familiar with it as Makefile.

As a first step to automate the tag removal, I added following ant target to call my Python script:

<target name="removeTags">
  <exec executable="python">
    <arg value="removeViewAllDiscoTopics.py" />
  </exec>
</target>

After that, I modified my custom target to automate the retrieval and deployment to call this target prior to deploying the retrieval to destination org:

<target name="deployAll">
  <antcall target="retrieve" />
  <antcall target="removeTags" />
  <antcall target="deploy" />
</target>

Take-away
Now, this does address the problem automating removal of this particular bug.  However, this does not address the underlying problem that you need to be aware of presence of such bugs and you have to create scripts to remove all occurrences of such bugs, which is clear limitation of the tool.  Also, using a custom script to massage the retrieved XML is something that I had to do to address other limitations of Force.com Migration Tool, and I will revisit this solution in future posts.  Finally, this is something that occurred precisely because the deployment happen during the Salesforce upgrade window.  This is something that is mentioned in recent Force.com webinar on deploy: From Sandbox to Production: Demystifying Force.com Release Management Part 1.  The suggestion from Salesforce.com in that webinar is to avoid deployment during the upgrade window, which is not practical for many enterprises due to their business cycle and which exposes one of the major limitation of Salesforce.com.

About this blog

As a Force.com Certified Developer with about a year of experience developing in Salesforce and over five years working in the industry as a developer, there are much to like about in doing development on Salesforce.com platform.  As a standardized platform, it does take care much of the UI design decision.  However you feel about the look-and-feel of Salesforce, this does make the lives of non-UX designers, like myself, easier.  Although I am not a huge fan of Salesforce having their custom programming languages and design of these languages, APEX, the programming language for Salesforce, and Visualforce, the mark-up language, are fairly easy to learn and they are making strong efforts to add features to these languages.  As well, you can see they are opening up more and more aspects of Salesforce, making it easier to interact with external system as well as build your custom solution on top of Salesforce platform.

However, one aspect that has been frustrated me is the lack of open forum to document the pitfalls and bugs in Salesforce platform.  The many discussion forums, both internal to Salesforce and external forums, such as StackOverflow, focuses on answering specific implementation questions.  Salesforce's Community forum does have Known Issue section; however, this only tracks some of the cases open against their support and that were deemed to be worthy to be documented publicly.  The problem with not having an open forum for such discussion is that it is difficult to identify whatever issue one is having is an isolated incidence or whether others are having similar issue and to have open discussion about work-around.

To this end, the purpose of this blog will be document the pitfalls and bugs in Salesforce platform found by this Force.com developer, so as to engage wider discussion on this issue, as well as to help others experiencing similar issue.  In addition to this, I will post about useful resources I find or upcoming Salesforce-related events that looks to be useful.  Finally, I might make some shameless plug on some of my works as well.

I hope those reading this blog find these posts useful in your Force.com Development work and encourage you to making Salesforce even better developer platform than it is.