Case event editing is available as of FogBugz 7.3. There's no time constraint.
Here's a link to the FogBugz Case Event Edit plugin:
http://www.fogcreek.com/FogBugz/plugins/plugin.aspx?ixPlugin=36
|
3 | added 123 characters in body | ||
|
|
||||
|
|
2 | deleted 1263 characters in body | ||
|
You're right. So far, the challenges with Case event editing or deletion have much more to do with storing history and reflecting the edit to the end-user than with the actual danger of providing edit or deletion capability. As this blog post on designing subcases makes clear, we're totally up for tackling tough design challenges when the pay-off is high. I like this line of thinking, available as it solves a lot of the challenges of reflecting status (purple vs. blue link color). The big danger with this implementation, though, is the same problem we've had with quick case add. If you only grant someone the ability to do something in certain circumstances, they get confused when they're unable to do so. I envision my days being filled with explaining to people why they can't edit their last entry. So the big design challenge here is to indicate to the user that this is a temporary, restricted function. Maybe we're talking more about an "undo" function rather than an edit function. If it were "undo", then that would imply deletion rather than editing. The notification emails, though, become the fly in the ointmentFogBugz 7.3. If I assign you a case, then undo my edit/assign, we need to somehow undo that notification in addition to changing the text, etcThere's no time constraint. |
||||
|
|
1 |
|
||
|
You're right. So far, the challenges with editing or deletion have much more to do with storing history and reflecting the edit to the end-user than with the actual danger of providing edit or deletion capability. As this blog post on designing subcases makes clear, we're totally up for tackling tough design challenges when the pay-off is high. I like this line of thinking, as it solves a lot of the challenges of reflecting status (purple vs. blue link color). The big danger with this implementation, though, is the same problem we've had with quick case add. If you only grant someone the ability to do something in certain circumstances, they get confused when they're unable to do so. I envision my days being filled with explaining to people why they can't edit their last entry. So the big design challenge here is to indicate to the user that this is a temporary, restricted function. Maybe we're talking more about an "undo" function rather than an edit function. If it were "undo", then that would imply deletion rather than editing. The notification emails, though, become the fly in the ointment. If I assign you a case, then undo my edit/assign, we need to somehow undo that notification in addition to changing the text, etc. |
||||
