A nested loop made ChangeComments#getCommentThreads O(n²) in the worst
case. Use a map to convert it to O(n).
Change-Id: I39f6a462cdd23316a1b513ebf98bbd2c8f9aaec2
These tags are preserved by the Closure compiler and vulcanize in order
to serve the license notices embedded in the outputs. In a standalone
Gerrit server, these license are also covered in the LICENSES.txt served
with the documentation. When serving PG assets from a CDN, it's less
obvious what the corresponding LICENSES.txt file is, since the CDN is
not directly linked to a running Gerrit server. Safer to embed the
licenses in the assets themselves.
Change-Id: Id1add1451fad1baa7916882a6bda02c326ccc988
In c/163510 I added the getCommentsForThreadGroup function but have
realized that it's simpler to get commments for the thread instead, as
the rootId is already known. This way, we can follow the same algorithm
to determine the thread based on the rootId, and in_reply_to to ensure
consistency.
Change-Id: I51ad4c6aa354de626c3ddb4fe1a21410b92c0465
Diff comments are threaded together based on the in_reply_to relation
(which potentially expresses a tree structure) but are always displayed
linearly in the UI. This means that some comments in the middle of a
linear thread may be actually stored as leaves of a tree.
For example, the following thread of comments can be created if comments
two and three are created at nearly the same time.
Comment 1: thread root, unresolved,
┣ Comment 2: in reply to comment 1, unresolved,
┗ Comment 3: also in reply to comment 1, unresolved,
┗ Comment 4: in reply to comment 3, resolved
Because the thread is flattened, the resolved state of the thread should
be determined by the state of the chronologically latest comment (#4),
resulting in this thread being considered as resolved.
However, in a couple of locations, the resolved state is counted
differently. Namely, it finds the "leaf" comments -- that is, the
comments that are not marked as the parent of any other comment -- and
the number of unresolved threads is determined as the number of
unresolved leaves.
This approach was used by:
- ChangeComments#computeUnresolvedNum in the UI, which determines
the string stating the number of unresolved threads in a file row.
- ChangeData#unresolvedCommentCount in the Java server code, which
determines, among other things, the value of the
unresolved_comment_count change detail property, as well as the Prolog
fact used by the Prolog recipe that requires all comments to be
resolved before a change can be submitted.
Instead, the unresolved thread logic is modified to group comments into
flat threads, and consider the resolved state of each one based on the
chronologically final comment, irregardless of the leaves.
Bug: Issue 8472
Change-Id: I2788fdb22ecfd56f0b3da763790a7732ec73be33
In order to support the new comment thread view, comments added to the
thread list need to be synchronized with expanded inline diffs. This
change adds a new method so that the comment API can be used to fetch
comments for a particular thread, after the thread creation occurs
originally in the diff builder.
Change-Id: I2430bf6a4fd9837cef3f633cb55db3719c99390a
The UI does not allow creating multiple comments at the same diff
location, but instead encourages contributing to the comment threads
already at a location. The uniqueness of thread locations was leveraged
to simplify the collection of comments into threads by mapping their
locations to keys.
However, the REST API does permit multiple threads starting from the
same diff location, so this expectation in the key-based UI threading
logic can be wrong. In such scenarios, an unresolved thread may be
mistakenly inserted into a resolved thread, resulting in a comment that
is not resolvable through the UI.
With this change, the `getCommentThreads` method is updated to associate
comments into threads via the `in_reply_to` graph rather than location
map in the same way that the `unresolved_comment_count` detail property
is determined server-side.
Although this corrects the issue in the `getCommentThreads` method, as
of this change, the diffs do not yet use it to thread comments.
Migrating diffs over to use it will be done in follow-up.
Bug: Issue 6779
Change-Id: I9427ccc716acdf7ef4c63eba48d2287875fa5534
- Updaotes the unresolved property to be public, and reflects the
attribute. This will be used for the toggle to show unresolved threads
or all threads.
- Update logic to always show drafts at the end of sorted comments.
Without this, the thread could get in a weird state where you can
still add another draft, but since they are not threaded, and once the
comment is published, its date changes to the published date anyway,
so its ordering will be at the end.
- This change also adds the __draft attribute in gr-diff-comment-api so
that draft comments will render correctly in the new view.
Change-Id: Icacc46ab5fd643b061ecfac8dcd313f815d17199
In merge changes, comments on a specific parent should not appear in the
non-specific auto-merge base patch. The CommentInfo field that indicates
this was formerly not taken into consideration.
Change-Id: I42b2afe013c0fc3a04dd1583d7677c6825e2c8af
This function also re-initializes a ChangeComment object, but uses the
old values for comments and robot comments, and only makes a request for
new drafts.
It's response is identical to loadAll for the purposes of elements using
these functions, but will reduce unneeded API calls.
Change-Id: I3c0872b86a0e24c9c378acf3311fe8cc3e078eda
Previously, nested components (that are never standalone) were making
their own requests for comments, creating unecessary duplicate API
requests.
Some requests were made to the rest API directly (for example,
gr-change-view requested comments this way), and some were through the
gr-comment-api, which also helped handle comment manipulation and
reorganization.
Instead of ad-hoc comment requesting, move all comment requests to the
top level (standalone) component, and use an object prototype to
generate _changeComments as a property on gr-comment-api. This is an
immutable object that can be passed to the inner components
(file list, etc), and includes the methods needed to manipulate
comments into the forms
necessary.
When a child component needs to trigger a refresh of the comments, fire
an event that the parent event handles (see gr-file-list l.867).
Bug: Issue 6953
Change-Id: Ic4b6cf16520baae65d8cf956c311a60f2a70a2e1
Because requests for a user's draft diff comments is always nested
within a check for whether a user is logged in, these can be combined
into the same REST API interface call. The updated call is given a JSDoc
to describe the additional functionality and call sites are simplified.
Change-Id: Idc0cc6298c7287579ba76e7cc35701e62142bca3
Formerly, gr-diff would make its own REST calls for diff comments in the
patch range and path being viewed. However, these calls by the diff view
were redundant to the more general comment requests made by either
gr-diff-view (which requests all comments to support skipping to the
next file with comments) or gr-change-view (which requests comments
individually for each inline diff).
With this change, the diff component no longer loads comments for
itself, but is rather provided the comments from its host view via a
public property. In this way the host view can load the more-general
comment data, and filter it down for the diff view's params.
Introduces the gr-comment-api component to simplify loading and
filtering diff comments for use by diff views. By using this new
component:
* The diff view makes only one request for comments (including drafts
and robot comments) to support skipping to the next comment and
displaying comments in the diff view.
* The change view makes only one request for comments for all inline
diffs.
Bug: Issue 5299
Change-Id: Ia14a01619f1f9881aa0d253fd3f49af9a17f3dce
