Prevent hiding the reply draft banner after deleting any comment.

Review Request #9367 — Created Nov. 13, 2017 and submitted

Review Board

A previous fix went in to make sure the reply draft banner would hide
when deleting comment replies, but it unconditionally hid after any
reply was deleted, even if it wasn't the last one on the review.

This fixes the problem by changing how some of this code works. There's
now only one place that controls the showing/hiding of the banner, which
uses the "hasDraftChanged" signal emitted by the view. The places
managing the banner were previously emitting this and also changing the
banner state, so now they only have to concern themselves with the

The major part of the fix involves tracking how many drafts there are on
the review. This is computed on render and as reply editors go in/out of
draft state. When there's no editors left, the banner is hidden.

Ideally, much of this logic and state would live in a model, but we're
currently using RB.Review as the model for this view. A future change
can simplify a lot of this by separating out much of the logic, state,
and signals.

Loaded a page with a reply banner and two draft comments. Saw through
debugging output that it had the proper count. Deleted a reply, saw the
new count and saw that the banner remained on page. Deleted one more and
saw that the banner went away, with a count of 0.

Added a new reply and saw the count and the banner appear. Deleted and they
both reset.

Unit tests passed.

  1. Ship It!
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-3.0.x (9c881b9)