I'm going to merge this into T11314, but I don't want to hard-code rules around specific names used by GitHub/GitLab. We can provide more tools to manage these refs, but I don't think the right tool is a bunch of hard-coded rules. These refs are real refs which exist in the repository, and Diffusion should be able to represent them. A driving use case for the original change was a desire to expose Gerrit refs.

@avivey I was hanging my head in RTFM shame, TBH.

I'm having trouble reproducing this, but maybe I'm not fully understanding what you're running into?

In the future, please report security issues via HackerOne: https://hackerone.com/phabricator -- notably, this allows us to award you a security bounty if you discover an issue.

I deployed that and created this masterpiece:

Almost certainly fallout from the increased strictness in D17616, thanks.

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

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.

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.

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

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 can't reproduce this in production (8f7983a5be3a56db5b79dc7c3a0eb470f1d7ca02):

I should also mention that phabricator.allow-email-users is false on this install. Another option to avoid backscatter spam could be to limit the error messages to registered users (maybe even regardless of that setting).

Version is stable, updated about 2 hours ago.

Version?

sorry!

I think you need to use your local Phabricator

Stumbled on this issue while trying to set up my first ever SVN repo through Phabricator. However got it working with the alternate solutions found in Phabrictor documentation itself and online forums(these may be obvious to regular SVN users already).

Yes, after revoking Conduit Access the mirror still works. It's weird... There must've been some other reason why Github rejected my key, unrelated to Conduit.

Presumably resolved.

Hello. I just to say what i finded solution.

I can't reproduce this. We mirror from this install without Conduit access enabled, and there is no conceivable reason that Conduit access should need to be enabled for this to work.

Sounds like this is resolved.

We get the same bug, except that it's worse because when you enlarge the file list, the splitter moves, reducing the available area for viewing the diff, but the scrollable file list doesn't get any wider! You still can't see the full filenames, which is what you wanted in the first place.

asdbkjsdad

Thanks for tryout out this workflow!

If that's the case, is there an alternative way to accomplish our goal in the product? Thanks!

I think we use workboards extensively, but this is the only company I've used Phab so I don't have a diverse sample set. We have workboards for subprojects, workboards for parent projects to view a team's list of new requests and high-level sprint plans (e.g. a backlog column, and a column for each sprint milestone). We click through on the milestone columns to view a sprint-specific workboard (typical Kanban columns).

In fact, I'm pretty surprised that your workflow doesn't hit major bugs/issues all the time, unless this stuff is currently far bugger than I believe it is. If you ever tag "Project Y" before moving a task to "Milestone 3", you'd no longer be able to move it from the workboard since it would vanish (until T11036)? Do you have a very specific sequence of organizational steps you take to avoid these issues? Are you just not using workboards at all?

(And, unless it's also bugged, I believe moving from a milestone to a non-milestone column on "Project X" should already strip subprojects. The proposed behavior just prevents there from being any subprojects to strip.)

I agree, I don't think project tags should ever be automatically removed.

I intend that it can not be in "Project X > Milestone 3" and "Project X > Project Y" simultaneously. Note that the parent projects are the same (both "X").

No, I don't mean that, as written.