BugNET

Our company is going to start using BugNET for issue tracking, but there are several things we need addressed.

If these things aren't currently done, I'll be happy to add the functionality myself and return it to the community, but I want to see what the current status is with relation to these things. it's possible there are already solutions that I'm unaware of.

The first, and most important issue, is that we're a custom software development shop and we want to expose the bug tracking to our clients. But we don't want client A to know anything about client B's software. So we need users to only see the projects they're members of. Right now, it appears users see all the projects, whether or not they're members of the project. Is there currently any plan on changing this?

Our second issue is that we want to have custom fields that some users can see and others can't. For example, we want a client to be able to provide a priority to the issues, but we want the developers to also be able to assign priorities. We don't want the clients to be able to see the priorities that the developers set (some of them micromanage enough as it is!)

Anyway, are there any plans for adding either of these things? If I were to add them myself (and I will if necessary, because we require it) would you want me to provide the code back? If so, I would appreciate any comments you might have regarding how you'd like to see the functionality implemented.

Actually, we've ended up hacking the code up quite a bit to get it to fit into our custom portal software. We're tying the authentication into our own system, adding some hooks to have it work with basecamp and a few other things.

I must have missed the public vs. private stuff on the projects. I'll look into that. Thanks. Didn't want to add it only to find it was there all along...

As for the field level restrictions, yes, we'll add field-level view and edit permissions on a per role basis and we'll also include the default fields. When the work is done, I'll provide the source so that you can incorporate it into your code if you so choose.

One thing that occurred to me is that, from an architectural point of view, BugNET would benefit a great deal from a more modular plugin-based system. For example, the SVN stuff is a bit of a hack. I don't mean for that to be insulting. It's not meant to be. I simply mean, a cleaner interface would allow the addition of the SVN stuff without any changes to the core code. Right now you have the separate SVN project, but the core code has support for the SVN browser. It would be better to have a generic version control browser and have a plugin architecture that would allow you to add SVN, CVS, Source Safe (God forbid), or whatever, via a plugin module, that implements an interface the browser would understand and use to populate itself.

Being able to hook into the menus and add functionality and to export interfaces that allow access to core data would really make it much easier for people to add functionality to the app without having to directly modify the base system.

Anyway, just my humble opinion.

Excellent. I have to say, I really like the system. Overall, the design is quite nice and the features already in it are pretty impressive.

I'm relatively new to web development. I've done about 7 years of winforms development with a little ASP.NET from time to time, but have been full-time ASP.NET for the past 6 months. In my winforms development, I don't think I ever wrote a medium or large sized app that didn't have a plugin system. .NET makes implementing a plugin system ridiculously easy.

I'm glad to see you're going to adopt that sort of model. I think it will help drive the development of new functionality by outside folks.