In a previous article, I pre-announced (with permission) the new plugin capabilities of FogBugz 7.0, which has now been released, and put out a call for ideas for functionality you’ve always wanted in the product. I didn’t get a lot of suggestions, so I opted to start with something that I’ve needed for my team.
The Issue
If you’ve used FogBugz for any length of time, you no doubt have learned that this software comes with a subscription to Joel’s dogma on the way bug tracking should work and the software has generally enforced it, although the last two releases have shown a marked departure from their previous hard-line position.
One thing that comes up fairly often in their discussion group is the desire for the ability to go back and delete/modify previous entries after they have been submitted. It isn’t hard to come up with a list of reasons you might want to do this, but here is mine anyway:
- Everyone makes spelling/grammar mistakes, no-one wants them permanently memorialized as a monument to their illiteracy.
- Once in a while, you accidentally add an update to the wrong case. While you can add another entry imploring people to ignore the previous one, it mucks up the case history and makes it confusing to read.
- While working on a complicated case they sometimes take a hard left turn and make every previous discussion in the case notes irrelevant and misleading, especially for testers who come in at the end of the case and have to make sense of what the fix/feature exactly is supposed to do.
However, I do see FogCreek’s position about not encouraging people to change history. For typos sure, but this capability could clearly be abused by a clever revisionist trying to hide their tracks.
FogBugz Scratchout Plugin
My compromise was to approximate the Wiki model of changing history, let people change things, but leave a visible audit trail. I built a plugin that lets you mark case history events as deprecated and display them with the strike-through CSS effect. There is even a tool-tip over the struck text with an explanation of why it was deprecated.
Also, scratchouts are completely reversible with a single click.
FogBugz Scratchout Screenshot
Future Plans
Event Editing: The current version of the plugin addresses situations #2 and #3 (above) reasonably well, but it doesn’t yet provide a way to edit an existing event. This is something I’d like to implement in a future version.
Real Deletes: I’m still working out how the permissions would work, but for those who aren’t worried about abuse, I’m considering a configuration option, or maybe a separate plug-in that allows a permanent delete of a case or event from the database.
Aesthetic improvements:
- The button is still ugly, and due to limitations on the plugin API, I haven’t been able to reliably put the scratchout/restore links where I wanted to, in the header above each event. At least not reliably for all browsers. Any CSS experts that want to take a crack at that, let me know.
- I’d like to do some visual effect so you didn’t need to hover over the text to see the scratchout reason, but I haven’t come up with an aesthetically appealing design for that yet.
Your ideas: If you are using this plugin and have some ideas for improvements, send them my way via comments on this post.
Available now at a plugin gallery near you!
If you have already upgraded to FogBugz 7.0, you can download and install the Scratchout plug-in from the FogBugz plugin gallery, it is also automatically available for all FogBugz on Demand users.
If you haven’t upgraded FogBugz yet, I strongly recommend it, the new version is a major step forward for the tool.
Filed under: News | Tagged: delete cases in fogbugz, FogBugz, plugin, scratchout |
Improving Software 
Any chance of making this open source so others could contribute? I’d love to try to add an option where the scratched out entries could be collapsed or hidden from view.
I’ve been thinking about doing that, but haven’t made up my mind yet. I really don’t have any intentions to try to sell this thing, so I probably will go that direction eventually.
In the meantime you might be able to accomplish what you want if you are proficient with CSS. Just edit the a.Scratchedout class in the scratchout.css file in the zip then re-install the plugin using your modified zip file. If you need any JavaScript in addition to the CSS changes to make it work, you could also use the BugMonkey plugin to accomplish that.
Please, please, please, let me know if that workaround doesn’t pan out for you. I could probably add that functionality fairly easy or at least modify the architecture to make it easier to implement using the CSS mod approach.
And if it does work, I’d appreciate a copy of the modified CSS file so I could make it available to other users of the plugin.
It appears, at least for me, that the most recent FB Scratchout
(2.0.0.0) does not work with FB 7.0.25 (DB 711 Build 848). [I updated
from 1.1.3.0 this morning.]
The Scratchout icon appears (above) the text that can be scratched,
however, when clicking on it, it does not scratchout the text. I
have tried this in IE8 and Chrome, both with the same behavior.
In addition, I tried to send this to your email address listed on the options page (jfuex@gmail.com); but got a hard bounce.
I could not find any better mechanism to relay this info to you.
Good catch. There was a problem with the distribution file. A corrected version (2.0.1) has been published to the FogBugz site.
Works Great! Thanks for the quick fix update!
Are you accepting ideas for enhancements?
If so, I think it would be nice to record (& show) the user that did the scratch out.
Thanks again! Love the plugin.
That’s a really good idea. I’ll put that in the next version.
Why Scratchout doesn’t work on Incoming mails?
Only on entries added by Edit.
That is an issue I have been working for a while.
When a case is e-mailed into FogBugz using an HTML formatted e-mail that HTML markup is included in the event history. Inconsistencies in the implementation of CSS across the browsers supported by FBSO make the strikeout effect less reliable when applied to an event that includes arbitrary html. For example, text in header tags remain visibly not scratched out even if the rest of the event text is.
For now, FBSO doesn’t enable the scratchout button on these cases, but let me know if this is a major concern for you and I’ll bump the priority on that issue.
Thanks for the quick reply!
Yes, this is very important for me (and my team).
We mostly work by e-mail and peoples make mistakes sending unnecessary mails (e.g. small discrepancy) to our FB.
Thanks in advance
Piotr
Hi johnfx,
I was developing a Web App that has to do with Fogbugz API. I was looking for a way to get the Scratchout of a specific Case in a specific area so that I can make some filters. Is there any way to get what tickets got scratched out and in which specific event in the ticket? Thank you,
Regards.
Yes, but not through the UI. The scratchout information is stored in a plug-in specific table. The table is named as “Plugin_9_BugEventScratchedOut” where 9 is the plugin ID, which changes for each install. You can find the plugin id by going to the configuration page for the Scratchout plugin. It will be at the end of the URL of that page.
For example: https://fogbugz.yourdomain.com/?pg=pgPluginConfig&ixPlugin=9
The name is determined in each specific install of FogBugz so I can’t tell you for sure what the name will be, but it will be prefixed with . If you go to the plugin list page and hover over the edit icon on the plugin the pluginID will be at the end of the URL.