Implement Private Changes
Private changes are only visible to owner, reviewers and users with the
configured permission. This lets users stage changes without
advertising their change, and conduct sensitive reviews (eg. security)
mong a small group.
- Add Private field to change in ReviewDb
- Check visibility for private changes
- Add permission that allows users to see all private changes
- Add Private Footer to NoteDb
- Add field for private changes to index and QueryBuilder
- Add REST endpoints to Mark/Unmark private change
- VisibleRefsFilter filters private changes
- GWT UI: Mark/Unmark change as private and show private label
- GWT UI: Show 'status (Private)' in ChangeTable.
- Support to control privacy of a change on push
- Add tests for reviewer visibility and new permission
- Add tests for query by private
- Add tests for advertised references
- Add user documentation in intro-user
To push a private change or to turn a change private on push the
'private' option can be specified:
git push host HEAD:refs/for/master%private
Removing the privacy flag should not happen accidentally, but should be
a very explicit action. This is why omitting the 'private' option when
pushing updates to a private change doesn't remove the privacy flag on
the change. To remove the privacy flag from a change on push the
'remove-private' option can be used:
git push host HEAD:refs/for/master%remove-private
Change-Id: Ib2b26ea19c0286cff9c05754b0875f61e5e9fceb
Signed-off-by: Edwin Kempin <ekempin@google.com>
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Patrick Hiesel <hiesel@google.com>
Signed-off-by: Changcheng Xiao <xchangcheng@google.com>
Signed-off-by: Alice Kober-Sotzek <aliceks@google.com>
This commit is contained in:
committed by
Han-Wen Nienhuys
parent
565a1510ae
commit
98ddc8a658
@@ -482,9 +482,50 @@ followed by `topic=...`.
|
||||
$ git push origin HEAD:refs/heads/master -o topic=multi-master
|
||||
----
|
||||
|
||||
[[private changes]]
|
||||
== Private changes
|
||||
|
||||
Private changes are changes that are only visible to their owners and
|
||||
reviewers. Private changes are useful in a number of cases:
|
||||
|
||||
* You want to check what the change looks before formal review starts.
|
||||
By marking the change private without reviewers, nobody can't
|
||||
prematurely comment on your changes.
|
||||
|
||||
* You want to use Gerrit to sync data between different devices. By
|
||||
creating a private throwaway change without reviewers, you can push
|
||||
from one device, and fetch to another device.
|
||||
|
||||
* You want to do code review on a change that has sensitive
|
||||
aspects. By reviewing a security fix in a private change,
|
||||
outsiders can't discover the fix before it is pushed out. Even after
|
||||
merging the change, the review can be kept private.
|
||||
|
||||
To create a private change, you push it with the `private` option.
|
||||
|
||||
.Push a private change
|
||||
----
|
||||
$ git commit
|
||||
$ git push origin HEAD:refs/for/master%private
|
||||
----
|
||||
|
||||
The change will remain private on subsequent pushes until you specify
|
||||
the `remove-private` option. Alternatively, the web UI provides buttons
|
||||
to mark a change private and non-private again.
|
||||
|
||||
For CI systems that must verify private changes, a special permission
|
||||
can be granted
|
||||
(link:access-control.html#category_view_private_changes[View Private Changes]).
|
||||
In that case, care should be taken to prevent the CI system from
|
||||
exposing secret details.
|
||||
|
||||
|
||||
[[drafts]]
|
||||
== Working with Drafts
|
||||
|
||||
Drafts is a deprecated feature and will be removed soon. Consider using
|
||||
private changes instead.
|
||||
|
||||
Changes can be uploaded as drafts. By default draft changes are only
|
||||
visible to the change owner. This gives you the possibility to have
|
||||
some staging before making your changes visible to the reviewers. Draft
|
||||
|
||||
Reference in New Issue
Block a user