FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at http://help.fogcreek.com/fogbugz.

Posts by Fog Creek Employees are marked:

Documentation
Release Notes
Network Status

Need roll-up reports for project hierarchies

We support a set of products that each consist of a generic framework that is customized for various clients.  We love the fine-grained permissions in 4.0 that allow us to share our bug database with clients without letting clients see each other's defect reports.  However, the same pool of developers supports the generic framework and client-specific customizations.  We want an ability to create a filter that shows all product issues regardless of client.

If we had only one product, we could get by with an "All Projects" roll-up.  But we have several products each with multiple supported major releases.  What’s lacking in FogBugz 4.0 is an ability to define a filter that includes multiple projects -- but not all projects.

Previously, we'd used Visual Intercept which allowed projects to be defined hierarchically.  We have project trees along the lines of:

Product A
    Release 1
        Internal
        Customer
            CustA
            CustB
Product B
    Release 1
        Internal
        Customer
            CustB
            CustD
            CustE
    Release 2
        Internal
        Customer
            CustA
            CustB
            CustC
            CustD

We want to create filters for "Product A" or "Product B Release 2".  Has such a capability been considered for FogBugz?

I would contend that you will have much more demand for this in 4.0 than you've had in the past because security is applied at the project level and this will lead your customers to create multiple projects where previously they might have been able to get by with areas.

If only FogBugz filters allowed for wildcard searches against Project name.  We could then define a naming convention for projects that would let us get the roll-up reports we need.  For the sample hierarchy above above, we might define the following list of FogBugz projects:

Product A/Release 1
Product A/Release 1/CustA
Product A/Release 1/CustB
Product B/Release 1
Product B/Release 1/CustB
Product B/Release 1/CustD
Product B/Release 1/CustE
Product B/Release 2
Product B/Release 2/CustA
Product B/Release 2/CustB
Product B/Release 2/CustC
Product B/Release 2/CustD

A list of projects could still be presented in a combobox on the Filter edit screen.  All that would need to be added is a checkbox: “Include subprojects”.  Internally, this would result in a SQL WHERE clause along the lines of “PROJECT LIKE @Project” versus Project = @Project”.
Jay Cincotta Send private email
Wednesday, March 2, 2005
 
 
Of course, it would be better if FogBugz supported true project hierarchies (i.e. ParentProject as a property of each project), but I was hoping to persuade you that a simple enhancement could be implemented quickly that would improve the value proposition for FogBugz 4.0.

I'd rather have a simple enhancement soon rather than waiting for a perfect implementation next year.
Jay Cincotta Send private email
Thursday, March 3, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.