Add a status of "Closed" to issues (BB-10249)

Issue #5179 closed
HBP created an issue

the workflow of a bug/issue should be - new -> open (when assgined to a dev) -> resolved -> closed (after QA verified the fix is OK)

Comments (39)

  1. Dylan Etkin

    Hi Tomer,

    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.



  2. HBP reporter

    (Reply via

    Hi Dylan. 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?


  3. Adam Gent

    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.

    Here is another request (there are many more like this... although people say different things a majority of them want just a "testing" state).... I should also state I'm a paying customer :)

  4. Vladimir Sizikov

    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.


  5. Aaron Stewart

    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!

  6. Avinus Team

    +1 Just noticed this problem. Have no way of telling the difference between fixed but not tested... and fixed+closed.

  7. Jason Keefer


    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.

  8. Steven Berlan

    +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.

  9. Jaime Olivares

    +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.

  10. jamesw

    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

  11. Jaime Olivares

    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.

  12. Алексей Стрелков

    that is a must-have feature, the issue tracker is not lightweight, it is just broken without it.

  13. Ilya Ber

    +1, so simple to implement, why not just do it? A bunch of your paying customers are suffering here.

  14. Ray Luo

    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.

  15. Brodie Rao
    • changed status to open

    We're reopening this issue and adding the feature to our backlog. We'll update this issue when we have more information.

  16. Arun Kumar

    +1 very difficult to manage the workflow, once the team is huge and the issues are more. I vote for this

  17. Michka Popoff

    Just wanted to thank @DataGreed for his script, it's working nicely, I closed 500 issues at once :)

  18. Log in to comment