We have decided to keep the issue tracker as simple as possible. We have resolved and we feel that represents the closed state.
If you are looking for something more customizable we would recommend JIRA.
(Reply via to...@cmycasa.com):
Thanks for the reply.
What is the flow you suggested then? When a developer fixes a bug, how
should he mark it so that QA knows its resolved? And how should QA,
after verifying that the bug is indeed resolved, mark it as closed so
he will be able to filter out verified bugs?
Dylan Etkin I think its great to keep the issue tracker simple (its in fact why we use it) but I and many others seem to need one more state in the workflow. Even Github and Google code allow this (through "labels", and "keywords" respectively)
And We are not asking to customize the workflow. We just need to indicate that the code is in but someone other than the developer who fixed needs to test it. So one more state is all that is needed.
Otherwise I have been having to use the Component field.
I totally agree here, we really do need one more workflow state. Otherwise it is just impossible to distinguish between old fixed/verified bugs and recently fixed ones.
Once the issue is fixed by developer, the QA should verify the bug and somehow mark it as verified. Even on smallish projects where there is no dedicated QA, it is very useful for developers themselves, so that they would distinguish between the old already verified and/or tested bugs and the newly fixed ones.
Please reconsider your decision and add just one new workflow state. If you don't wish to increase the number of states, then it makes sense to remove one of invalid/wontfix sates, one of them is more than enough.
I agree totally. I admire simplicity, but when testing can't be represented, it's too simple.
Just replace one of invalid/wontfix with testing or closed, please!
+1 for that feature - QA must know what bugs he needs to verify.
+1 We can't live without this state of workflow. Now we have a chaos in bugtracker.
+1 Just noticed this problem. Have no way of telling the difference between fixed but not tested... and fixed+closed.
Issue #7364 was marked as a duplicate of this issue.
I have been using the Issue Tracker for one of my projects. I am used to using expensive trackers in funded business settings, and while there are many features that BitBucket does not emulate, one thing I am sorely missing which I'm not sure I can live without is the ability to set a bug status as "Claim Fixed/Resolved", so that the original tester/QA can go back and test to see if the bug has actually been resolved. This creates an ideal work-flow dynamic, where bugs are not just marked Resolved, but they are earmarked to be re-tested before being verified to be actually Resolved.
Closed status or custom status required !!!
+1 Closed status
+1 Closed status
It is irritating sifting through the All tab in issues because a lack of consideration for a verified fixed workflow status.
QA is part of the standard lifecycle of developing software. You should not be using this crippling oversimplification to push Jira.
+1 for Closed or Verified
+1 for Closed, Verified or Approved. The goal of simplicity is not broken here, since it would be a non-customizable addition.
By the way, there is a new Vote feature all you guys can use for voting for this feature. Hope somebody is hearing us.
I'm not voting on this issue as I believe closed is the same as resolved but I do feel a testing workflow item is needed as requested here and would masively enhance bitbuket with no (as in 0) compromise on simplicity
A developer can say it is resolved, but he/she is not entitled to close/approve an issue since it is not the product owner or stakeholder and doesn't represent him.
that is a must-have feature, the issue tracker is not lightweight, it is just broken without it.
+1, this missing feature is blocking our migration to BitBucket all together ...
+1, so simple to implement, why not just do it? A bunch of your paying customers are suffering here.
+1 for an added state
Why hasn't this been added?
I am not sure if everybody is using the Vote link, or just typing +1
I've already voted using the Vote link, but this issue is so important that I must write a post here and hope the bitbucket team can see it:
HOW COME ADDING ONE MORE "CLOSED" STATE WOULD MAKE THE ISSUE TRACKER NOT SIMPLE ANYMORE? It is so easy to implement this new feature, it is also easy for end user to use it, and it is even as easy as right now if an end user decide to not use it. So what is the logic behind this "keep it simple"?
My guess is that the issue tracker was originally designed for (and perhaps by?) solo developer, who takes full authority to say whether a bug is done; when he said it is "resolved", he means "closed". This assumption is fundamentally wrong when a project becomes serious and involves QA team and management team.
Please, bitbucket team, wake up.
Issue #9064 was marked as a duplicate of this issue.