Skip to end of metadata
Go to start of metadata

Comments in Crucible can be used to flag a defect in the code under review.

To do this, simply check Defect when adding a comment and select a category from the drop-down list.

Screenshot: Defects

You may want to mark comments as defects in order to associate defect classifications, or simply to highlight to the author or moderator that the issue you raised in your comment requires attention. You can use the with defects filter to find files that have been flagged with defects.

(info) Crucible intentionally does not mandate how defects are to be used. The Crucible administrator can customise the defect classifications.

(info) You can only use the defect classifications on comments that are not a reply to an existing comment.


  1. This seems quite poor to me.  To the folks here: Flagging Defects as well.  Yet all comments such as this go unnoticed - or at least unanswered.   If really all you are doing is providing a means to change the background color of the comment from yellow to red, why not supply a color picker?  That would provide way more options!  However, as a user it is important to be able to flag review comments as a defect and have a way to enforce that they are closed and/or addressed prior to closing the review.  Can anyone please comment?

    1. Hi Joe,

      "Crucible intentionally does not mandate how defects are to be used." Please raise a feature request if you would like to see a change here.

      Marking as a defect does more than change the background colour. For example, you can use the 'Show content... with defects' filter to find files that have been flagged with defects.

      regards, Paul

      1. Joseph Gamache: I agree, and I would phrase it even more strongly.  "Flagging Defects" is a broken feature:

        • If you don't edit and unflag it before closing the review, then it looks like X defects made it right through code review and into the code base.
        • If you do unflag it, then there's no way to see that a defect was noted in the code review and subsequently resolved.

        IMO The feature request to resolve this would involve unresolved defects preventing a code review from being closed and forcing a resolution on each defect comment (perhaps a configurable value with options like: "RESOLVED" and "WON'T FIX").  Otherwise, it really is just a view change (color + filter).

        @Paul Watson [Atlassian] - if you included a link to where the feature request should be raised, and possibly gave some tip on how to avoid it being ignored, there's a lot better chance it would get reported.

        1. Additional thoughts now.

          I think it is great that Crucible CAN be used as a standalone project.  However, what about your customer's (like us) that also use JIRA?  There SHOULD be a way the behavior between YOUR TWO tools can be integrated....

        2. Fair enough, Stanley! The 'Report a Bug' button at the bottom of this page links to the public Crucible issue tracker at Once there, click Create issue at the top of your screen, and choose a suitable Issue type, such as 'Bug' or 'New Feature'.

          As you can imagine, issues raised in this way get prioritised according to a number of factors... the more information you can provide about your use case and the impact on your workflow, the better we can understand the improvement and work that may be called for.

  2. If the person who posted the defect to the review leaves the company, is there a way an administrator can edit the defect for them, or transfer ownership to another user, so that Classification fields on those defects can be updated/corrected?