Random Assignment

Thursday, August 26, 2010 by Rich Armstrong

Up until recently, our support team used a pick-and-choose-type issue selection, where we go through the Inbox project, browsing through issues, seeing which cases we'll deign to spend our precious mental resources on.

Bad idea. First, by time you evaluate the issue to see if it's something you'll deign to spend your precious mental resources on, you've already spent time on it. So have the other three people who looked at it and decided they didn't want it. Every extra person who looks at an issue wastes their time on it.

Second, you tend to get skewed skills. It's much better to expose the entire support staff to the full breadth of requests coming into a given queue. Otherwise, you get things like one LDAP guy who can never go on vacation.

To mitigate this, we've taken two steps. First, we used the FogBugz Python API to create a random assignment script. This script gathers all the cases that come in via email and via our Twitter feed monitor script.  It sorts them by correspondent. That way, you don't spend twenty minutes answering a question while your colleague has gotten the "never mind, I found it" email. Then we dole them out to the people working in the Inbox at the time. If you're out of the office or working on a plug-in, you have a case assigned to you that takes you out of the pool. We rely on the law of large numbers (and the fact that we're not automatons) to spread out the work.

It's been tremendously successful. We all noticed a big productivity bump.

Actions: E-mail | Permalink

New Product and Howto Videos

Thursday, July 22, 2010 by Dan Ostlund

We've posted new videos on our Fog Creek video page

Earlier this summer we decided to experiment with some new ways of getting out information about FogBugz and Kiln, and since we had the talented Lerone Wilson already doing some video work for us, making product videos was an easy choice.

A lot of the product videos were--what shall we say?--a little on the boring side.  We wanted to make something a little better than you usually see and avoid all the usual mistakes, like having your bored product manager mumble his lines through his nose.

We ran through our actor options here, but most of us sounded like Keanu Reeves, only dead.

Since we're in New York we put out a call for actors and got dozens of submissions from some really talented people, and found a guy we liked.  Only later did we discover that he's a veteran of the Onion News Network. (NSFW - Swearing).  He was a lot of fun to work with.

That's it really.  A few days of filming and we had video covering all of the major parts of FogBugz and our new product Kiln.  We had a half day of time left that we had paid for so we added some "Howto" videos describing common tasks in FogBugz.

We hope these are useful!  We'd love to hear what you think, and if there are other topics you would like us to cover, let us know.

Categories: FogCreek | Kiln | FogBugz
Tags:
Actions: E-mail | Permalink

How I learned to stop worrying and love the plugins

Thursday, July 22, 2010 by Michael H. Pryor
I noticed that FogBugz spam on public discussion groups started heating up recently.  Apparently someone who has zombie bots (coming from all different IPs) has added them to its attack vector. Unfortunately most of the posts are 'similar' but not 100%, and the Bayesian filter doesn't pick up all of them.  We're helping this some in the next release of FogBugz by using honeypots, but the bot makers are getting smarter and that's becoming less effective.  We really need captchas.
 
I have not written any code in probably six months and the dev team is working on our next major release with the interns, so I didn't want to interrupt them to handle this.   Lucky for me, you don't really need to know that much to implement this plugin.
  1. Start with the bare bones instructions on making a "hello world" plugin.   Your code should end up looking like so:

        public class Recaptcha : Plugin
        {
           public Recaptcha(CPluginApi api)
                : base(api)
            {
            }
        }

  2. Make your class inherit from the IPluginDiscussTopicCommit interface (we want to make sure posts are not created if the captcha is not correct) and the IPluginDiscussTopicDisplay interface (so we can show the captcha on the page).

        public class Recaptcha : Plugin, IPluginDiscussTopicCommit, IPluginDiscussTopicDisplay
        {
           public Recaptcha(CPluginApi api)
                : base(api)
            {
            }
        }

    Note: Visual Studio and Visual C# Express make adding these methods easy. Once you type IPluginDiscussTopicCommit as an interface to implement, hover over IPluginDiscussTopicCommit and the "I" will be underlined. Hover over that and a menu appears. Click the menu and choose "Implement Interface 'IPluginDiscussTopicCommit'" and it will create the method stubs for you!

  3. Head on over to the ReCaptcha site (now owned by Google) and sign up to get your private and public key.
  4. In DiscussTopicDisplayPostCreate we just return a new CDialogItem with the HTML from the ReCaptcha site.
  5. In DiscussTopicCommitBefore we just check the captcha form variables match using the ReCaptcha API.  If it matches, return true.  Else return false.
Two tricks: First, FogBugz makes it a bit obscureto read form variables that aren't prefixed with api.GetPluginPrefix.  Thisisn't for security; it's so people don't rely on FogBugz form variables as anunpublished API.  In our case, we can't mess with the names of the inputs thatReCaptcha uses because they are tweaked at run time by a JS file downloaded fromGoogle's servers.  But we do have jQuery in FogBugz,  so I added two linesof jQuery that rename the input fields after the Google script has run to have theAPI prefix in their name.  The other trick was just to not use the ReCaptcha ifit's a logged in user.
 
Download the source:  

Recaptcha.cs (4.14kb)

 

Actions: E-mail | Permalink

Cheeky Python: A Redis CLI

Wednesday, July 21, 2010 by TGHW

Recently, at work, we started using MiniRedis as a lightweight store for some job queuing on Kiln's backend. We had originally planned on using the full Redis, but because we have to deploy licensed Kiln on Windows, we had to come up with our own solution.

So far, it's been working very well for us. The Redis command set is pretty small and very straightforward, which makes it easy to clone. The only annoyance we've run into is that the stable command line interface (CLI) for Redis only speaks the 1.x protocol, while MiniRedis only speaks the 2.0 version. The redis CLI also does not run on Windows. This is a bit of a problem, since we're still working on our queuing system and we need to do testing.

To get around not having a client to use, Ben would telnet in to the MiniRedis port and type out the commands manually. It ended up looking a bit like this:

I, on the other hand, would fire up Python and, using the redis-py library (which is a very nice client library), issue commands directly from there. Neither option was very convenient.

So one day, tired of having to do all the imports and set up the connection, I decided to put together a CLI using Python.

import cmd

class RedisCli(cmd.Cmd, object):
    pass

if __name__ == '__main__':
    RedisCli().cmdloop()

The basic CLI is very simple. Python's cmd module takes care of all the hard parts for you. If you run this script, you'll get a prompt (Cmd) that supports one command: help. Unfortunately, that's all you have. You can't even exit gracefully. So that's the first thing I added:

class RedisCli(cmd.Cmd, object):
    def do_exit(self, line):
        return True
    do_EOF = do_exit

The cmd module lets you define commands by writing a do_foo() method which takes the line the user typed in. The above code gives you the exit command, and also makes EOF (Unix: Ctrl-D, Windows: Ctrl-Z) exit for you. That's helpful, but it doesn't really add much in terms of actual functionality. For that, we import the Redis client libraries

from redis import Redis

initialize the connection

class RedisCli(cmd.Cmd, object):
    def __init__(self, host, port):
        self.redis = Redis(host=host, port=port)

and add some of the Redis commands

    def do_get(self, line):
        print self.redis.get(line)

    def do_set(self, line):
        key, value = line.split()
        print self.redis.set(key, value)

This is nice, because help will now list get and set. But Redis has many more commands available. One option would be to continue adding all the Redis commands until you had the full set specified and properly parsing the command line. That's pretty time consuming, brittle, and just plain boring. Personally, I don't have the patience.

Fortunately, the cmd module has a default() method which is called for any unrecognized functions. That means we can get rid of do_get and do_set and replace them with:

    def default(self, line):
        parts = line.split()
        print getattr(self.redis, parts[0])(*parts[1:])

Huh? Let me explain: getattr() takes an object and an attribute name, and returns that attribute if it exists. To illustrate, calling getattr(obj, 'foo') is the same as calling obj.foo. In this case, we're assuming the user typed in one of the functions defined in the Redis object. We use getattr to get that function, and then we pass the rest of the arguments to it using Python's *args syntax. This sidesteps the problem of not knowing how many arguments the commands take.

Unfortunately, this approach is prone to errors. For example, the user can type in __init__, which will call the Redis object's constructor again, overwriting our connection. Someone could also try to call foobarbazbat, which does not exist in the Redis object and will throw an error. Lastly, we've also lost our list of commands when you type help.

To fix this, we're going to have to do some spelunking in the Redis object. Fortunately, Python's dir() function returns all of the Redis object's attributes. We can then iterate over them, filter out any that start with an underscore (Python's convention for private attributes) and make sure they're callable. We then use setattr to create a function in our own class that calls into the Redis object and prints the result.

    def __init__(self, host, port):
        super(RedisCli, self).__init__()
        self.redis = Redis(host=host, port=port)
        for name in dir(self.redis):
            if not name.startswith('_'):
                attr = getattr(self.redis, name)
                if callable(attr):
                    setattr(self.__class__, 'do_' + name, self._make_cmd(name))

    @staticmethod
    def _make_cmd(name):
        def handler(self, line):
            parts = line.split()
            print getattr(self.redis, name)(*parts)
        return handler

Notice here that _make_cmd is creating a new function inside of it, and returning that function so we can set the do_foo of our own class to the function that calls self.redis.foo(). Likewise for any callable function in the Redis class.

Now if we type help on our command line, we'll get a list of all functions in the Redis object. Also, if we try to access anything private, like __init__, we'll be told that syntax is unknown. This also means that our default() method is no longer necessary, since we've already enumerated everything that we could possibly call on the Redis object.

You'll notice, however, that help lists all of the functions as "Undocumented". It would be really nice if we could also get documentation for each of these commands. Now that we can easily list all of the available commands, we could write the documentation ourselves by specifying a help_foo() function for each command. However, this is boring and like I said before, I don't have that kind of patience. It also turns out that writing our own documentation would be redundant, as the authors of our Redis client library have done a good job documenting each function in the form of docstrings:

def get(self, name):
    """
    Return the value at key ``name``, or None of the key doesn't exist
    """

Python takes these docstrings pretty seriously. In fact, they become an attribute of the function itself, called __doc__. This is great for us, because it means we can pull those docstrings into our CLI and make them documentation for our commands. We use the same method as before to dynamically add help_foo() methods to our own class for every function that has a docstring:

    doc = (getattr(func, '__doc__', '') or '').strip()
    if doc:  # Not everything has a docstring
        setattr(self.__class__, 'help_' + name, self._make_help(doc))

    @staticmethod
    def _make_help(self, doc):
        def help(self):
            print doc
        return help

So now if we type help, we'll get a list of "Documented" and "Undocumented" commands. If we type help get, it'll tell us "Return the value at key ``name``, or None of the key doesn't exist." Awesome!

This is getting to be a useful little CLI. In addition to having a documented list of all commands available, we also get tab completion for our commands, so if we type l<TAB>, we get the list of all list commands. (On Windows, you'll need the pyreadline module installed for this to work.) But what if we could also autocomplete our keys? Some of our keys get pretty long, and typing them out is a pain. We could define a complete_foo() method for each of our functions, but all we're ever going to be completing are the keys, so we can just use the completedefault, which is a catchall completion, to grab our keys for us.

    def completedefault(self, text, line, start, end):
        return self.redis.keys(text + '*').split()

Once we've added this, we can type get bar<TAB> and we'll get all of the keys that start with bar.

We're in the home stretch now. Just to make things a little nicer, let's modify the prompt and the intro message so the user knows they're in the Redis CLI:

    def __init__(self, host, port):
        ...
        self.prompt = '(Redis) '
        self.intro = '\nConnected to Redis on %s:%d' % (host, port)

And finally, because this is a tool we want to be able to use with different servers, let's add the ability to specify a host (-h or --host) and port (-p or --port).

import getopt

if __name__ == '__main__':
    opts = dict(getopt.getopt(sys.argv[1:], 'h:p:', ['host=', 'port='])[0])
    host = opts.get('-h', None) or opts.get('--host', 'localhost')
    port = int(opts.get('-p', None) or opts.get('--port', 12345))
    RedisCli(host=host, port=port).cmdloop()

To finish, we just add some error checking so we don't get bailed out with an exception if we happen to make a typo. Here's the final script:

import cmd
import getopt
import sys

from redis import Redis
from redis.exceptions import ConnectionError, ResponseError

class RedisCli(cmd.Cmd, object):
    def __init__(self, host, port):
        super(RedisCli, self).__init__()
        self.redis = Redis(host=host, port=port)
        self.prompt = '(Redis) '
        self.intro = '\nConnected to Redis on %s:%d' % (host, port)
        for name in dir(self.redis):
            if not name.startswith('_'):
                attr = getattr(self.redis, name)
                if callable(attr):
                    setattr(self.__class__, 'do_' + name, self._make_cmd(name))
                    doc = (getattr(attr, '__doc__', '') or '').strip()
                    if doc:
                        doc = (' ' * 8) + doc  # Fix up the indentation
                        setattr(self.__class__, 'help_' + name, self._make_help(doc))
        try:
            # Test the connection. It doesn't matter if 'a' exists or not.
            self.redis.get('a')
        except ConnectionError, e:
            print e
            sys.exit(1)

    @staticmethod
    def _make_cmd(name):
        def handler(self, line):
            parts = line.split()
            try:
                print getattr(self.redis, name)(*parts)
            except Exception, e:
                print 'Error:', e
        return handler

    @staticmethod
    def _make_help(doc):
        def help(self):
            print doc
        return help

    def completedefault(self, text, line, start, end):
        return self.redis.keys(text + '*').split()

    def do_exit(self, line):
        return True
    do_EOF = do_exit

    def emptyline(self):
        pass  # By default, cmd repeats the command. We don't want to do that.

if __name__ == '__main__':
    opts = dict(getopt.getopt(sys.argv[1:], 'h:p:', ['host=', 'port='])[0])
    host = opts.get('-h', None) or opts.get('--host', 'localhost')
    port = int(opts.get('-p', None) or opts.get('--port', 12345))
    RedisCli(host=host, port=port).cmdloop()

And there we have it. A full-featured, robust, well-documented Redis CLI in about 60 lines of code. For comparison, the C version is over 500 lines of code, and has no help documentation or code completion.

The best part, though, is that this doesn't really know anything about Redis at all. The only parts that are aware of Redis are __init__(), which sets up the Redis object, and completedefault(), which gets our keys. That means that you could easily adapt this script to be a CLI on top of any client library you have.

Cross posted from http://hicks-wright.net/blog/cheeky-python-a-redis-cli/.

Categories: General | Kiln
Actions: E-mail | Permalink

SQL Server 2008 Express

Tuesday, June 15, 2010 by Rich Armstrong

We found out recently that SQL Server 2008 Express, the free edition of SQL Server, has increased its database size limit from 4GB to 10GB!

SQL Server is an enterprise-grade database that runs FogBugz flawlessly and almost never corrupts or crashes. In our experience, for running FogBugz, it's far superior to MySQL or Access.

How much usage can you expect before exceeding 10GB? Well, it depends on how you use the software. If you're using FogBugz for regular email correspondence with your users (with normal size attachments), it would take a few years to hit this limit, and we can help you clear out old stuff when that day comes, extending your free usage by a year or more. If you're not using FogBugz for email, attachments, or large log files, you'll probably be fine until The Singularity.

Categories: General | FogBugz
Actions: E-mail | Permalink

FogBugz 7.3 Now Available

Monday, May 17, 2010 by Dan Wilson

(Click here to skip straight to the "What's New" page.)

FogBugz 7.3 has been released!  We've completed updating all of our On Demand customers' sites and the FogBugz 7.3.0 installer is nowavailable to all Licensed FogBugz customers with an up-to-date support contract.  If you're reading this and are not yet a customer, there's nobetter time to start a free trial of FogBugz, the premier issue tracking and project management tool for software teams.

We've been listening to our customers closely, and the list of major features in FogBugz 7.3 reads like a direct response to some of their most common requests:

1. New Plugin: Case Event Edit

Some of our customers are forced to follow a standards-compliant caseworkflow preventing them from making changes to data previously committed to a FogBugz case.  But others don't operate under such constraints, and wonder why FogBugz won't let them go back and fix their typos or sightly incorrect bug descriptions.

Well, we're pleased to announce that those customers can now go to the FogBugz Plugin Gallery and get the Case Event Edit Plugin. Once installed, a subtle "edit" control will appear next to every case event containing user-entered text or an attachment. Clicking on the link will open up anediting form right inline:

...And a complete edit history for the case event is preserved and is viewable at any time:


2. Resizable Case View

For years, the layout of the FogBugz case view has had a static width that we've thought optimal for readability.  Having heard from many users who disagree with our assessment, we've decided to change the width to, well, whatever the user wants it to be.

Using an intuitive set of drag handles, you can make the width of the case view arbitrarily wide, as well as fine-tune the relative width of the left and right columns.
 

3. Improved Agile/Scrum Support

FogBugz 7.3 users will be able to install the new and improved Project Backlog Plugin, which allows for AJAX-enabled editing of the backlog right from the FogBugz Case List.
 

4. IMAP Support

Organizations that don't want to open up their email servers to POP3 traffic will be happy to hear that FogBugz mailboxes can now grab incoming email messages using the IMAP protocol.
 

 
5. Bulk Reply and Improved Bulk Editing

FogBugz 7.3 allows you to handle large groups of cases like never before. To send a group of correspondents the same email message, a you can just highlight several cases and click "Reply."  While authoring an email in the bulk reply interface, you'll be able to use the preview pane to make sure your reply is right for allrecipients, and even use special snippet tokens to include case-specific information in each email.
 

 
In addition, for all types of bulk editing, a new "Event History" pane below the editing controls lets you flip through the complete history of each case you're editing.
 
 

These are just the bigger features and fixes in FogBugz 7.3; to get the complete story check out the official 7.3.0 release notes.

We at Fog Creek Software know that FogBugz plays a critically important role in keeping thousands of software businesses running, and we remain committed to keeping our users happy and productive.  We hope you enjoy using FogBugz 7.3, and look forward to hearing your feedback via the FogBugz Knowledge Exchange or by email.
 
Actions: E-mail | Permalink

FogBugz Consultant Wanted

Wednesday, May 12, 2010 by Michael H. Pryor

We have a customer who is need of assistance.  They are looking for a consultant who is familiar with FogBugz and can help them with:

  • Perform Gap analysis
  • Analysis of current FogBugz configuration
  • Analysis of current FogBugz usage(i.e. workflow)
  • Current Issues being encountered
  • Reporting status
  • Tracking progress
  • Others identified during discussions/interviews with company users
  • Recommend Solutions
  • Provide\Brief estimate for labor, materials, and training(if necessary) to implement improvements
  • Implement Solution
  • Implement Improvements as approved by the company from the recommendations given
The work would be done at their offices in Orlando, FL.  We'd love to get some time down south in sunny Florida ourselves, but we're way too busy working on the next version of FogBugz.
 
If you can help out, please send your info to damian at fogcreek.
Actions: E-mail | Permalink

LadyBugz: A New FogBugz Client for Macintosh

Thursday, April 08, 2010 by Dan Wilson

Lithograph Software has just released Version 1.1 of LadyBugz, their FogBugz client for Mac OS X.  It's an extremely complete solution that deeply integrates FogBugz into your desktop, and makes use of popular OS X UI conventions:

  • Cases can be assigned just by dragging and dropping to a particular FogBugz user.
  • Replies to customer inquiries look and feel just like the mac native Mail app.
  • Cases and events can be viewed in independent windows.
If you're an OS X user, LadyBugz is definitely worth checking out.  It's now available for trial and purchase on the Lithoglyph site.
Actions: E-mail | Permalink

Custom Landing Pages

Tuesday, March 09, 2010 by Jude Allred
 

Behold the FogBugz landing page:

In its default form, this page is very useful to people desiring to log on to FogBugz.  Outside of that, it’s potentially useful as a portal for external users to access documentation and file cases, however the scope of that usefulness is limited by its lack of customizability.

Or rather, it was limited. 

In the advanced section of your FogBugz site configuration, there’s a new option for selecting a custom landing page. 

 

All of your publicly-visible FogBugz wiki pages will be available on this list- simply choose one and it will replace the default landing page.  I've selected the 'Project AwesomeCat' wiki to be my landing page.

If you’ve done nothing other than select an existing Wiki as the new landing page, then visitors to your FogBugz site will see something relatively like this:

Save your Oooooo’s and Aaaaaah's for just a moment-  there’s something significant about this screenshot.  See that little Log On link in the corner?

The only thing about this custom landing page which is not fluidly customizable is that little Log On interface, and even that could be altered with a little bit of jQuery.

The mechanism for customization is now the FogBugz wiki: Your landing page will look exactly like its corresponding wiki page... In fact, they're the same thing. To alter content, alter the wiki page.  To change the look and feel, visit the wiki customization page and edit your wiki’s template:

You can view the thrilling conclusion of the Project AwesomeCat custom landing page at LandingPageDemo.FogBugz.com

As a more practical example, these same techniques are in play over at Developers.Fogbugz.com  

Categories: FogBugz
Actions: E-mail | Permalink

We need your help! The Kiln licensed beta is here

Monday, January 25, 2010 by Jason Rosoff

This is a call for beta testers interested in trying out our new version control product: Kiln (http://www.kilnhg.com/). Mercurial is the version control system under the hood, so if you've got FogBugz and wanted to try out a DVCS, this is a great opportunity. If you just want to experience the awesomeness of version control, code review, and bug tracking all working together seamlessly, this is a great opportunity.

I have to mention that this is a beta. There will be some bugs during installation, and possibly after. The good news is that Kiln has been running for several months and hosting production code for a bunch of people in the On Demand environment. We think the risk is pretty low, but as software developers you know there is no way for us to guarantee that there won't be bugs.

We are specifically looking for licensed (install it on your server) testers, although you can use the same form if you're a FogBugz on Demand customer (the more the merrier!):

https://shop.fogcreek.com/beta-kiln/

Licensed Kiln will only run on Windows 2003/2008 Server with SQL Server 2005/2008/2008 Express. Folks running other operating systems or database servers are out of luck for the time being.

ONE MORE THING: This release also introduces a new version of FogBugz. There have been a few UI changes to support having FogBugz integrate with other applications. If you don't want to test Kiln, but would be willing to test the new version of FogBugz, send me an email to jason (at) fogcreek (dot) com.

Categories: Kiln | FogBugz
Actions: E-mail | Permalink

Tickets: A FogBugz Client for Mac

Monday, January 18, 2010 by Dan Wilson

Manicwave Productions has just released Tickets (v1.0), a Mac OS X client for FogBugz. It provides an elegant Cocoa interface for fast, easy case entry.  You can also attach screenshots, and use an integrated status bar menu to browse the history of recently created cases.  Tickets even provides excellent features for power users, including support for Global Hotkeys and Applescript automation.

Tickets requires Mac OS X 10.6+, and is available for purchase on the Manicwave website.

Actions: E-mail | Permalink

Get the Fog Creek Developer Newsletter

Friday, January 08, 2010 by Dan Wilson

We've just started sending out an email newsletter to Fog Creek customers who are interested in:

  • Classic articles on software development and project management
  • Release announcements concerning offerings from Fog Creek and its partners
  • Helpful how-to guides for FogBugz and other Fog Creek products such as Kiln and StackExchange
  • Links to new posts appearing on this blog

Sign up here: http://www.fogcreek.com/FogBugz/Newsletter.aspx

And check out the web-based copy of Issue #1 (sent out this week) right here: http://media.fogcreek.com/newsletter/2010/Newsletter1.html

Newsletters will go out roughly twice a month. Feel free to forward them along to friends and coworkers!

Actions: E-mail | Permalink

SnapABug Visual Customer Support

Tuesday, December 01, 2009 by Dan Wilson

The FogBugz Team is pleased to invite another product into our partner ecosystem: SnapABug Visual Customer Support.

SnapABug allows website designers to quickly and easily embed a small (but powerful) "Help" widget in their site. When a user of the site experiences a problem and clicks the control, they're presented with a small form that gathers their email address, a short description of the problem, and (optionally) a screenshot of what they're seeing on the website.

Here's the best part: if you use FogBugz to track your customer issues (and honestly, why wouldn't you), you can configure SnapABug to automatically generate a FogBugz case that contains all the data entered into the SnapABug form, with screenshot attached.  It's never been so easy to run a responsive help desk for your customers: instead of spending valuable time determining the particulars of the problem, you can use SnapABug to quickly discover, reproduce and diagnose the bugs getting in the way of your users' happiness.

Learn more about SnapABug and start a free trial at http://www.snapabug.com/.

Actions: E-mail | Permalink

Old FogBugz Discussion Topics

Thursday, November 19, 2009 by Michael H. Pryor

We've had a recent problem with potential and current customers finding old and outdated information on our discussion boards.  One option we had was to archive the discussion board each time we have a new release (probably the best idea), but we didn't do that unfortunately.  Our other option is to just erase all old topics from our database (not nice to Google and we don't want people to think we're hiding our warts). The third option is to leave the content up and figure out a way to really make sure people know the info they are about to see no longer applies to our current product (probably).  It took me about ten minutes to come up with a solution using the BugMonkey plugin, which allows you to insert arbitrary JavaScript and CSS into your FogBugz site.

You can see an example in this post about FogBugz 4.0.

You can view the code I used for the lightbox effect.

You can also download and view the javascript: sample.js (880.00 bytes)

In doing this I realized it would helpful if there was a systematic id system for text portions of the page (in this case, it was difficult for me to get the date of the topic, since I didn't want it to be applied to current topics). Definitely something to think about in the future...

 

Categories: FogCreek | FogBugz
Actions: E-mail | Permalink

Foglyn: The FogBugz Plugin for Eclipse

Wednesday, November 18, 2009 by Dan Wilson

FogBugz users who develop in the Eclipse IDE should have a serious look at Foglyn, an Eclipse plugin by Peter Štibraný that allows you to view, organize, and manipulate your FogBugz cases without ever leaving the IDE. 

Foglyn smartly builds upon the Mylyn task management interface to make it perfect for use with FogBugz:

Eclipse users can visit www.foglyn.com to download the plugin and try it free for 45 days.

Actions: E-mail | Permalink