Fog Creek Software
Discussion Board

Please enchance FB consistency

As I posted recently in this forum at:

I am facing this problem almost daily. Are you considering doing something about this? I do not want to have a policy that a user must hold its case so anyone else cannot edit it.

Please let me know what you think or if I can do something to properly solve this important issue.


Alexandre B. Corrêa
Monday, May 12, 2003

We also experience this problem in this scenario:

We have defined a user named "Technical Support", to which every incoming email is assigned by default. Our policy is: when a technical support agent wants to work on this case and take care of it, the first thing he must do before anything else is assign the case to himself.

Sometimes, two support agents will try to assign the case to themselves at the same time. Of course, there will only be 1 winner - the last agent to click "Ok". But in the meantime, the other agent does not know that the bug is not really assigned to him, because Agent 2 will click "OK" seconds after him...


Pascal Bourque
Monday, May 12, 2003

I think this is the weakest part of FB.

I'm wondering how it will be soon, when I would need to increase the total number of users. Nowadays, with only 30 and a few users, this problem happens almost daily.

Imagine a scennario with hundreds of users.

Alexandre B. Corrêa
Tuesday, May 13, 2003

Pascal: to address this problem, we set up FogBUGZ so that the minute one user hits "Reply," the bug is automatically assigned to them. You don't have to do it manually. You do have to check, before you start typing your reply, that nobody else hit reply at exactly the same time.

If you have a largish team of people answering inquiries, you may be better off with a single person who takes responsibility of passing out cases, rather than having people grab cases out of the pool.

This is the first version of FogBUGZ that really supports answering customer email, and it's not perfect yet; we'll improve it in the next version.

Joel Spolsky
Thursday, May 15, 2003

Alexandre: I suspect you would be much more unhappy if FogBUGZ actually implemented record locking so that while one user is editing a bug, all others are locked out. The first problem is that we don't know when they have decided not to edit the bug; they may have walked away from the computer or even navigated to another page and the bug remains locked.

However I can think of one possible solution -- when you change a bug, if someone else has changed the same bug while you were making your change (e.g. between the time you got the form to edit the bug and the time you submitted), we can detect this case and give you a yellow post-it warning telling you that someone else edited the bug while you were editing it, and you should double check for conflicts.

Joel Spolsky
Thursday, May 15, 2003


Would be too hard to make the edit function start with the combo fields set as "unchanged" ? So that, unless you mess with them, even if other person edits the same bug, you won't undo what other person did.
Of course, if the person explicitly changes the same field, I don't want FB to "do magic".


Luciano R. M. Silva
Friday, May 16, 2003


  I just want this problem solved. I have suggested some solutions, but I get the point I don't care and I don't have enough time to discuss one or another technnical solution (for instance, using record locking or not), but as an user I am really disappointed in the way this IMPORTANT problem is being handled by FogBugz.

Alexandre B. Corrêa
Friday, May 16, 2003

Luciano's solution or similar sounds great to me.

Alexandre B. Corrêa
Friday, May 16, 2003


  Please check:

  I post something related to this on that topic.



Felipe W Damasio
Friday, May 16, 2003

We'll here are my two cents on a possible fix. It is not a complete fix, but at least it will prevent data from being lost when two users decide to edit the same case.

Add a field to the table, for simplicity sake make it a date and call it LastUpdated. Every time an edit takes place this date will be set with the server date. An integer could also be used, but I think the date might be a little better.

So basically:

- ASP reads record to be edited along with this date
- User makes changes
- User submits changes

On Submit
- Does the date in the ASP match the value stored in the DB?
  - If Yes, update the field first, then Apply changes
  - If No, Do not apply changes and let user know that someone else has already modified the file you are looking at.

Odin Ortiz
Friday, May 16, 2003

any news?

Alexandre B. Corrêa
Tuesday, May 20, 2003

Still awaiting...

Alexandre B. Corrêa
Wednesday, May 28, 2003


We're looking at a fix for the next release.  Thanks for your patience.

Michael H. Pryor
Wednesday, May 28, 2003

FWIW, the .NET framework handles this with very little effort. Here's how we've chosen to implement it on our high-volume apps (exactly as Joel mentioned above):
1- user A clicks edit
2- user B clicks edit
3- user A saves
4- user B tries to save, but a "validation error" pops up saying the record was edited by XX while they were editing it. No option is given to overwrite.

Easy to do because, IIR the DataAdapter throws a ConcurrencyViolation, comparing the old record to the new record. It's free! Yaay .NET!

- Jake

Friday, June 20, 2003

*  Recent Topics

*  Fog Creek Home