tree aa944e177110ed96c1d4667b7c80aa507b5cf8b7
parent fb5b95005fb2aa718365ddfc6d3da1c3faa13f26
author Edwin Kempin <ekempin@google.com> 1624612623 +0200
committer Edwin Kempin <ekempin@google.com> 1634740475 +0200

Make GetOwnedPaths REST endpoint more useable

At the moment the GetOwnedPaths REST endpoint is rather simple, it
returns a plain list of all paths that were touched in the revision and
that are owned by the specified user.

This plain list of owned paths mixes old and new paths from additions,
deletions and renames.

The limit was applied to the number of owned paths, e.g. if a revision
contained a rename and a file addition and all paths were owned by the
user, and the REST endpoint was invoked with limit = 2, it was returning
the old and the new path for the rename, but not the path for the
addition (since the limit was already exhausted by the 2 paths of the
rename).

This made it difficult to use this REST endpoint in the frontend. E.g.
an intended use case is to highlight all files in the file list that are
owned by the current user. If a change touches many files, the change
screen only shows the first 250 files. This means the frontend would
like to check for these 250 files whether they are owned by the current
user. Setting the limit to 250 on the GetOwnedPath REST endpoint would
result in too few owned paths returned if the revision contains
renames where new and old path are both owned by the user (in the change
screen renames count as 1 entry, while the GetOwnedPath REST endpoint
may count renames as 2 entries).

Now the frontend could try to get owned paths with a higher limit to
compensate this, but this wouldn't work reliably.

Another use case would be to offer a UI that lists the files that are
owned by a user with pagination. Since the returned list of owned paths
mixes new and old paths, the ordering would not be consistent across
pages. E.g. the first page would contain all owned path from the first
n changed files and the second page would contain all owned paths from
the second n changed files. Now each page is sorted alphabetically but
the first page may include old paths from renames, which would logically
sort only after entries from the second page (e.g. imagine a rename from
xyz/foo.md to abc/foo.md). To implement paging properly, the UI would
need to show the changed files in the same order as on the change
screen, e.g. show only 1 entry for a rename, but doing this is difficult
since from the list of owned paths the caller doesn't know which ones
are new and old paths and which 2 paths belong to 1 rename.

To make this easier, we add a new field to the response that returns
owner information by changed files, which can be additions, deletions
but also renames. The entities in this field have the same order as the
changed files on the change screen. The limit on the request is now
appliying to the number of entities in this list rather than in the
owned paths list. This way renames count only as 1 entry, which matches
the counting on the change screen. Changed files where the user neither
owns the new or old path are omitted. For each changed file in the
response we return the new and the old path (if present), regardless of
whether the user owns them, so that the caller can detect renames. For
the new and old path we set a marker if the file is owned by the user so
that the caller can know for renames which of the 2 paths the user owns.

For backwards compatibility reasons we keep the old plain list of owned
paths. Now it just contains all new and old owned paths that are
returned as part of the new structure that represents owned paths. There
may even be some use-cases where renames do not matter and a consumption
of this plain list is just easier.

Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I2d538ba25323fcfecbd6346d4507293902548383