August 30th, 2012 by Quentin Schroeder
At Long Last: The Case Merge Plugin!
We have a variety of methods for tracking what features our users are looking for, and by every measurement available, the ability to Merge Cases was at the top of the list! In fact, this has been a top feature request for quite some time.
We’ve had our eyes on this feature for a while now and even drafted a feature specification for it, but while we were drafting ideas, a user from the FogBugz Developer Community contacted us with a fully functional plugin that solved the problem! So, without further ado, may I present the Case Event Merge Plugin, written and generously shared by the developers at Quarantainenet:
“The FogBugz Case Event Merge plugin adds the functionality to display the case events of a duplicate case in the original case…. We have tried to overcome the design problem of merging by not merging at all: we just display the events of one case in the history of the other, keeping the workflow of cases intact.”
Here’s a quick video that goes over how it works:
The Case Event Merge Plugin is available for both FogBugz On Demand and customers running FogBugz on their own server. Follow the installation instructions to get started, and check out the full documentation to see what the authors have to say about it. Read on for a bit of history on the development of this plugin.
Why was this feature so hard to add?
After Quarantainenet knocked the ball out of the park with this plugin, it is easy to look at it and wonder why Fog Creek didn’t deliver it earlier. The answer lies in the details, or to be more accurate, the lack of details.
The solution that Quarantainenet devised is simple because it does not manipulate the existing rows in the database. In the feature specification draft that we were working on at FogCreek for merging cases, we were looking at it from the opposite perspective and dealing with the repercussions of trying to move the bug events from one case to the other within the database. In this scenario we had a lot of corner cases and questions that weren’t trivial to deal with.
- Once a case is merged to another, does the system delete it?
- What happens with new incoming emails that have the case number for the now-closed duplicate case?
- Do we try to merge the attributes of the two cases together?
- How do you seamlessly transition the conversation to the new case and discourage updates to the old one?
Each of these questions has valid possible solutions that we considered, but would lock the users into a specific workflow, which was something we were trying to avoid. The ability to merge cases had to make life easier for users who kept getting emails with the Case keyword stripped from it, or those infamous CC chains that seem to spawn an endless number of new cases. The solutions we were batting around made life easier in about eight out of ten scenarios, but made life a lot more confusing in those last two cases. The net gain was teetering on the edge of positive, which meant producing it just wasn’t worthwhile.
A Fresh Approach
The genius of the Case Event Merge Plugin is that the only data it requires is a marker for the duplicate cases whose events we want to display in the other case. The real work comes when FogBugz goes to render a case view page; the plugin interacts with the rendering process and creates a bunch of “pseudo bug events” from the duplicate cases. (The Kiln plugin uses the same pseudo bug event mechanism to show changesets inline with the rest of the case). These events are read from the database just as they would be if the user went to view the closed duplicate case. What this means is that the Plugin can crash, fail, be deleted, mucked with and otherwise abused and your original data is left completely intact.
Because Quarantainenet was never thinking about manipulating the existing Bug and BugEvent tables, their solution exclusively utilizes the rendering of the case view. This means that all of the core FogBugz code gets to keep chugging happily along, completely oblivious to the fact that these two cases are anything but “Resolved as Duplicates”! It’s simple, elegant, and it just works.
This plugin is already being used heavily at Fog Creek and we know many of our customers are excited about its release as well. Several years after the feature request first appeared, we’re glad that we can finally mark it as Resolved (Implemented).