When pushing changes/patch sets and when making change updates through
the REST API callers can specify a 'notify' option to control who
should be notified (not all REST endpoints support this option). This
'notify' option allows to choose if owner, reviewers, watchers and
users that have starred the change should be notified, or if no
notification should be send. For some tools this is not sufficient as
they want to have full control over which users should be notified.
E.g. if a CI integration is triggered by a certain label, the owner
and the user that triggered the CI should be notified.
To support this the REST API input entities that support the 'notify'
option are extended by a 'notify_details' options that allows the
caller to specify accounts that should be notified. These accounts are
always notified, even if notifications are otherwise disabled by
setting 'notify' to 'NONE'.
The 'notify_details' option is a map that maps a recipient type to a
'NotifyInfo' entity. This means callers can control how the accounts
should be notified, as TO, CC or BCC. The 'NotifyInfo' entity hosts
the list of accounts that should be notified. It is an extra entity so
that further entities that should be notified can be added in future.
E.g. one could imagine to add a list of emails (for user without
Gerrit account), a list of groups or a list of star labels (notify all
users that have set this star label on the change).
Also when pushing commits for review, specific accounts can be
explicitly notified by setting 'notify-to=<email>',
'notify-cc=<email>' or 'notify-bcc=<email>' in the push specification:
git push origin HEAD:refs/for/master%notify-to=foo@bar.com
These accounts are not added as reviewer or CC so that they are not
signed up to receive notifications for futher updates of the change.
Change-Id: Id112b70158b80f84f631b5022f33228871716108
Signed-off-by: Edwin Kempin <ekempin@google.com>
cd07df425d