tree 734b54a9ee374c41e2dd706a736ac34d768917c8
parent f94a1643f8b2676a774d9de87071dccdea82a74f
author Kamil Musin <kamilm@google.com> 1721827956 +0200
committer Kamil Musin <kamilm@google.com> 1721904952 +0200

Fix onBehalfOf behaviour of Submit

When submitting changes using onBehalfOf only permission of the user
triggering the Submit need to be considered. With an Ic6dbda6de that
logic got broken, it was no longer possible to submit changes on behalf
of another user, if that user didn't have the SUBMIT permission
themselves.

This change fixes this issue by using IdentifiedUser.getRealUser() in
MergeOp where appropriate based on the situation.

Additionally as part of this change we address the pre-existing issue,
where the SUBMIT_AS permission for active user and READ permission for
on-behalf-of user would only be checked for the triggering change and
not for all changes in the Submission. This lead to potential cases of
submitting changes as part of the topic that they would otherwise lack
permissions to submit. The extra checks for the "current change" in
Submit.java are kept, to allow the possibility of an early exit, as
construction of the full Set of changes to be submitted together is an
expensive task.

By using real user and on-behalf-of user in MergeOp we are able to
address another issue, where only READ permission of the on-behalf-of
user were considered when constructing Merge Set. With this change we
use real user's permission for constructing the Merge Set, but also
validate on-behalf-of READ permissions as well once it's constructed.

We also fix the permission check in ProjectConfigValidator, where
on-behalf-of user would be previously checked instead of the real user
performing the Submit.

Also added some class docstrings for some of the classes, that I ran
across during investigation.

Release-Notes: skip
Google-Bug-Id: b/351138952
Change-Id: Ib126d5fb75ab46620e302d35aa4a75699739732c