Are there any plans to implement a "Client" field for a case?
Right now we've created one project per client using a naming convention to keep them seperate from other projects (Client: Company Name). However the list of projects is getting quite huge.
What I'd really like to have is a combo box with "active" clients in it (when you create/edit a case). This way I can put the case under the proper project/application but still look things up by Client.
I know you can re-label the computer/version fields but you still have to type in the client's name...people might type it differently and it would cause problems. A combo box would be better.
Wednesday, July 9, 2003
One thing we're thinking of doing is adding a new feature called Project Groups. You can group a bunch of projects into a single group. Would this solve it for ya?
Friday, July 11, 2003
I'm not sure. A grouping system would give me the ability to make a single group for "Clients" and other categories like "Developer Utilities", etc. I definitely like the idea of groups for that reason.
However, if we have a bug, feature, or inquiry for one of our Application projects, how I can I link one of those cases to a client?
I think that a client field would be more useful to us since the existing filter system would naturally allow us to view cases for just one client acrossed many projects or products. Then we could track time based on who we're doing the work for.
Since I have your ear, I have some other ideas that you may have already thought of :-) Here they are.
-Allow one administrator to create filters for other users.
-Groups for filters (like HierMenus or something).
-An easy way to email a group of people (not only FogBugz users) associated with a project.
Thanks for your reply and for a very useful product.
Sunday, July 13, 2003
I was thinking, you would make a group for each client. Each client has one or more projects.
Then, for example, you could give members of the client's team permission on their own group but they couldn't see/edit bugs in any other group.
Monday, July 14, 2003
We currently implement Client tracking by having a Project called 'Customer List'. When a new customer is created, we create a Case for them, which gives us a case number to reference with bugs. It even lets us keep track of the current version of the software the customer is running.
Things I like about this system:
o. Changes are tracked
o. Can reference bugs to customers and vice-versa
Things I don't like:
o. I cannot see the "Version" in the Grid View bug list
o. Have to manually set and reset customer <-> bug references.
o. No large editable textbox field, so there's no good place to list contact information or system information (we used to use a Wiki for this, and then manually update a changelog).
...I could go on for days about how Fog Creek should write a CRM package as their next project. :)
Monday, July 14, 2003
Like I said, the groups will help us better organize in many ways as you've confirmed. However, when a case is entered by our tech-support reps we have a choice of putting the case in the "client project" for that client (so we can track by client) or in our "application project" (where we have to put the client's name in "Computer" or "Version" field to create a relation).
Just to be clear, I'm not begging for a feature to be added, I just wanted to know if it was in the works or not. If not I don't mind adding this myself. I'm fairly confident that it would involve the following steps:
Add a table called EndUser to the FogBugz db.
Add a nullable foreign-key field (ixEndUser) to the Bug table
Add an administrative page to allow management of End Users.
Modify the existing asp code to allow me to read/write to Bug.ixEndUser.
BTW, If you're not wanting to add this functionality because you ARE planning on releasing some kind of CRM for software shops I will be looking forward to purchasing that instead :)
Monday, July 14, 2003
In addition to the numerous additional requests for this feature, we too are hoping to add a customer field (and possibly contact name/number) to allow us to have our customer support guys use FogBUGZ
They have used FogBUGZ when reporting bugs from the field and we've spoiled them. Now they want to use it themselves.
Just to be clear, we are in the same position as the previous poster. We are going to have to figure out a way to make this happen using FogBUGZ or not (everyone would prefer to use it).
We are even prepared to discuss addtional costs to have you guys do this for us if necessary (you have my email address).
I understand your arguments against these addtional fields, but I do not agree with them. This may even be an add-on for FogBUGZ - I'm sure there are many people that would like this feature.
We have urgent requirements for this, so we can take this off-line for further discussion if you like.
Monday, August 11, 2003
I agree wholeheartedly with previous posts requesting a "Client" field available for issues. I am evaluating whether to start using FogBugz or not, and this is a critical question. I too must find someway to do it.
On a side note, I hope you folks at Fog Creek are not as dogmatic about extra fields as the founders of Apple. (eg there will never be arrow keys on an Apple keyboard.).
If you allowed people to add custom fields to adapt to their needs, they could help themselves. I like advice and guidance, but not being hamstrung.
Sunday, February 1, 2004
My team is currently evaluating FogBugz, and client tracking could be a deal breaker.
We're a small shop with a young product, so we have lots of requests from multiple clients - both bugs and features. We're interested in making sure that every weekly release addresses a few issues for each client.
A simple dropdown list that could be filtered would facilitate this beautifully, however the options I have seen in this discussion look pretty kludgy. Is there a better way to do this in the current software?
Thursday, August 19, 2004
Fog Creek Home