F60036 now plays correctly for me in Safari.

The video in T12078 now plays correctly for me so I think this is, in fact, resolved.

Thank you for explaining - I didn't mean to imply I thought it was a security concern, as it is very clear what giving someone Edit access means.

T4721 (which I also linked on the HackerOne report) discusses usability improvements to Passphrase, including better documentation and hinting about this use case and possibly the separation of the "Can Use Credential" and "Can View Secret" policies. These are reasonable usability concerns.

It sounds like the user is confused that having View access doesn't let them have access to decrypt/see the secret - only that they can use the secret within Phabricator. So in order to allow others to decrypt/see the secret he gives them Edit access which does give them the ability to change the secret.

Thanks for the response Evan.

You can review the HackerOne report, including my response, here:

mm, yeah, I didn't actually read it 😊 @kfsone said in the chat that it can be resolved, but this does actually sound like trust email address should win over require-email-verification.

@avivey Trust Email Address is meant to handle that though, is it not? The reported "bug" here is that the email addresses are not being verified when coming from LDAP, not that email verification is required.

auth.email-domains implies auth.require-email-verification.

After D17614, arc download uses file.search to retrieve a URI it can GET, then does a normal HTTP GET to that URI, retrieving the file content in the HTTP response body.

How about this:

@avivey Implementation of T8092 is eagerly awaited, I am merely proposing a stop-gap solution of hiding the diff and base tags listed on the Diffusion UI for a repo when the same repo is being used as a staging area.
This would greatly reduce the UI clutter and allow teams to use tags as an effective version tracking solution.

(This isn't really very closely related to the Files application anymore, just cleaning up that board a little.)

I'm also slightly confused because, as someone just reminded me, the usual behavior of arc patch is to apply the patch to the appropriate base commit for the revision, not to try to do it on the current HEAD. In this context, that seems like it'd mean applying it directly to the arcpatch-A branch, rather than try to cherry-pick that commit up on top of where the user ran arc patch from.

Also T6482 seems like it's fixed. I've been quite appreciating how Arcanist is increasingly aware of dependencies between revisions.

Great! Let us know if you run into anything else.

thanks, this worked for me!

Yeah, the long-term plans are "automatic staging areas", which are essentially some kind of hidden refs (Probably using T8092 though, not just hiding stuff).

It was a little unclear in the walkthrough you gave on how to use it. Are the field types (animal.type plant.habitat) suppose to be hidden by default on when using a specific subtype (animal.type on plant subtype)?

Oh, of course. Good catch.

This feature was promoted in the week 12 release, see notes: https://secure.phabricator.com/w/changelog/2017.12/. Please remember to always upgrade Phabricator before filing a bug report, this task would not have needed to have been filed if you followed our guidelines on Contributing Bug Reports, specifically https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#common-fixes

I cherry-picked this to stable and will plan to push it to the cluster tomorrow morning.

We need to check programmatically whether all the reviewers approved. Any suggestion how this could be done?

This is also not a valid feature request.

Could you reopen and set it as feature request?

(This isn't related to the "Search" application, even though it's about searching for things.)

This does not describe a bug in Phabricator.

I implemented this recently but then pulled it out because ... project slug lookup is a gigantic mess right now.

@dreadlord2203 indeed, hiding those tags would be useful. I found one problem with using a separate repository for change handoff, and that is access control. If you maintain several repositories with different access controls, then you would have to duplicate each of them and maintain a second set of access controls for the corresponding staging repositories. This is a lot of extra work and it would be easy to make a mistake and leak the staging repo to people who shouldn't be able to see it.

I've gotten way behind this week so I'm going to cut and deploy the release now to try to catch up, then fix this afterwards and deploy it separately.