commit | cb2fc552e359395a07116b29fcb1e8f877818f91 | [log] [tgz] |
---|---|---|
author | Edwin Kempin <ekempin@google.com> | Fri Jun 25 11:17:03 2021 +0200 |
committer | Edwin Kempin <ekempin@google.com> | Wed Oct 20 16:34:35 2021 +0200 |
tree | aa944e177110ed96c1d4667b7c80aa507b5cf8b7 | |
parent | fb5b95005fb2aa718365ddfc6d3da1c3faa13f26 [diff] |
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
This plugin provides support for defining code owners for files in a repository.
If the code-owners plugin is enabled, changes can only be submitted if all touched files are covered by approvals from code owners.
Also see resources/Documentation/about.md.
IMPORTANT: Before installing/enabling the plugin follow the instructions from the setup guide, see resources/Documentation/setup-guide.md.