Make differentials public by default for some projects

Hey there everyone!

I’ve seen that on our open source projects the diffs are created with visibility restricted to the users, while the repository and the project are public and accessible to guests. I’ve noticed that seems to have diffs set to being public by default or that there is .

I haven’t found any documentation that indicates that the visibility of diffs can be either achieved by adding anything to the diff messages, the .arcconfig file or similar. So I thought I’d ask if anyone had suggestions. ^^

Thanks in advance for your time!

More Application > Configure button in Differential > Edit Policies > set Default view policy to Public.

I originally wondered if Phab would expose nonpublic repository’s review to the public view, but it seems like it already thought of it.

As @revi notes above, to view a revision, you must be able to see the revision itself (D123) and the repository the revision belongs to (rXYZ). You can click the policy tag in the revision’s header (or any other object’s header) to review policy rules for that object, per the screenshot.

Setting the default policy to “Public” will mean that revisions against public repositories are public, and revisions against non-public policies have the same effective policy as the corresponding repository.

The risk here is that newly created revisions with no repository will become public by default (this change is not retroactive).

Normally, the repository for a revision is set automatically when it is generated with arc diff. However, if a user copy/pastes a diff into the web UI or makes a configuration mistake (or adds a new repository and doesn’t set it up in Phabricator), they may generate revisions that are associated with no repository or the wrong repository.

This may be a reasonable risk to accept, but if you have a large number of users interacting with non-public repositories that have differing levels of comfort with Phabricator, and/or your non-public repositories are very secret, you may want to be careful before making this change since user error could leak information about non-public repositories.

There is no granular way to selectively set revision policies based on associated repositories. There is no technical reason Herald couldn’t do this, but I’ve avoided adding “Set policy to…” actions to Herald because these actions can lock users out of objects in a way that is difficult to understand or recover from.

This action is fairly easy to implement as an extension if you’re ambitious, but note that in this case it creates some additional complexity/ambiguity if a revision’s repository changes after creation time. This is rare, but a revision may legitimately change repository in response to review feedback like “instead of working around this this in the client repository, let’s fix the underlying bug in the server repository” or similar.