At the moment Gerrit supports only one kind of star on changes, either
a change is starred by a user or it is not. For some use cases users
want to put different stars on changes. E.g. issue 1144 requests
colored stars (yellow, red, blue) and issue 2576 requests an ignore
star.
Star labels behave like private hashtags. A user can apply any label
to a change, but these labels are only visible to that user.
Having support for stars allows us to implement a first working
version of the ReviewIt Gerrit Android application.
To support star labels the API of StarredChangesUtil is extended so
that it can read/store star labels.
Star labels are stored in the change index. This is needed to be able
to return the star labels as part of ChangeInfo without needing to
scan for them. Including the star labels into ChangeInfo is done in a
follow-up change so that a online migration is possible, where search
results don't need to read from git:
1. The star labels are stored in the index, changes retured as query
results do not contain star labels (this change).
2. Run online schema migration, when finished the index contains the
new STAR field for all changes.
3. Include the star labels into ChangeInfo, access to git is not
needed since the star labels are read from the index (next change).
Also the STAR field in the index enables a new search operator for
star labels ("star:<label>") that finds changes that have been starred
by the current user with the given label
The STARREDBY field and the IsStarredByPredicate will be no longer
needed since the 'is:starred' query that they serve can be implemented
by using the new STAR field and the new StarPredicate. This is why the
STARREDBY field is and the IsStarredByPredicate predicate are
deprecated.
In addition a STARBY field is added to the index that tracks all users
that have starred the change with any label. This field is needed to
be able to list all starred changes (changes that have at least one
star by the user). Without this field we would need to scan the full
refs/starred-changes/ namespace for this. The STARBY field also backs
a new 'has:stars' query operator which finds all changes that have at
least one star by the current user.
The REST API is extended so that users can get/add/remove star labels.
New REST endpoints have been added to
- get star labels from a change
GET /accounts/<account-id>/stars.changes/<change-id>
- update star labels on a change
POST /accounts/<account-id>/stars.changes/<change-id>
- list changes that are starred by any label
GET /accounts/<account-id>/stars.changes/
The REST endpoints that deal with the default stars are left
unmodified for backwards compatibility. They are exposed under
'/accounts/<id>/starred.changes/'.
Star labels are private to a user, hence a user can access only the
own star labels.
New methods have been added to the AccountApi to support get and
update of star labels, and listing of changes that have been starred
with any label.
Star labels also affect the ETag of a change. Instead of including the
actual labels into the ETag computation we simply use the ID of the
object in which the labels are stored in git. This way we don't need
to read the blob for the ETag computation.
The old method to retrieve starred changes from an IdentifiedUser and
the way to load the starred changes asynchroniously is deprecated now.
The asynchronous loading was needed when the starred changes were
(slowly) loaded from the database, but the new lookup is faster so
that we no longer need this asynchronous loading. The code for this is
still kept so that we can still support IsStarredByLegacyPredicate
which is needed to find starred changes when the change index doesn't
contain the new star fields yet.
Change-Id: I25d8af5a2a26930320c074225e26ff032889c891
Signed-off-by: Edwin Kempin <ekempin@google.com>
9e972ccb44