When Fog Creek released FogBugz 7, I’m told they thought they were doing a good thing by merging the confusing “Clients and Departments” feature, which almost nobody used, into the “Groups” feature, which everyone would understand. This would’ve been a great plan had your average person’s understanding of a “group” been “a list of permissions that can be applied to one or more projects.” Unfortunately, it’s not. Most people think “group” and think of their favorite band or a group activity. In short, they think of a group of people.
A bit of FogBugz history
The idea behind Clients and Departments was that you would segment your Projects based on which client or department they were related to. As such, it was assumed you would mainly care about keeping permissions for Clients and Departments distinct, and that if you wanted to assign permissions, each permission granted would apply to everything in that Client or Department. This made some sense, but was hard to grok and not very flexible.
Some blame can be placed on merging Clients and Departments under Groups. The term implied more flexibility than was actually in the software. A lot of people tried to use FogBugz 7 Groups as if they were user groups, but you couldn’t give multiple Groups access to the same project. Weird, right?
The way forward
After realizing how super-confused people were about FogBugz 7 Groups, we took a good long look at things and thought “maybe we should make Groups work more like people think they should work.” After talking to a lot of our customers, we realized this would make a lot of people happier, even if that meant some short-term pain during the transition.
In FogBugz 8, Groups work like they do everywhere else in the known world of software (and also, probably, in your brain). Groups are now simply reusable collections of users to which you can grant permissions. Huzzah!
Setting permissions in FogBugz 8
Permissions are now defined directly on Projects, Wikis, and Discussion Groups, where they belong. You can now grant permission on a project to an individual, or to a group (of users). In addition, we’ve also cleaned and spiffed up the interface for configuring permissions:
The only change to permissions that people will see when upgrading to FogBugz 8 is the elimination of Group Administrators. This little-used feature made sense in the old implementation, but when groups became groups of people (not groups of permissions) they just didn’t make much sense anymore. (Don’t worry, if you actually need to worry about this, we’ll tell you when you upgrade and walk you through how to address it.)
Other than this change, permissions should operate exactly as they did before upgrading. This took some doing, and when you upgrade to FogBugz 8, there might be some shuffling, but the end result is something we feel to be a much more flexible and intuitive permission system. We’re hoping it’ll be worth the effort from us as well as you!