Neither T11277 or T6706 are exactly about that, but I think the ultimate fix to those is likely a general refinement of SSH key metadata (source IP range restrictions, logging, specific permissions).

for sshd and ignore the username

I'd expect to just hide that in CLI porcelain:

This is unique to this particular setup check (open_basedir configured, but not in a way that creates a concrete problem we're able to detect).

https://secure.phabricator.com/diffusion/P/browse/master/src/applications/project/lipsum/PhabricatorProjectNameContextFreeGrammar.php

D16542 should fix this and reveal whatever the underlying error is.

Yes, if you want the change to apply retroactively. Something like bin/repository reparse --message --all rXYZ, but see bin/repository help reparse first to test that on a few commits and make sure it does what you want.

I don't think this is preview related -- I think PhabricatorEditEngineConfigurationTransaction just doesn't implement hasChangeDetails() and some related methods to generate this link.

There is no such setting, and I believe this use case is very unusual -- it's like putting the subject line of email in the first line of the body -- so I currently have no plans to add support for it (see also T8227).

Sorry, we don't offer setup and configuration help. See Support Resources for discussion of what we do offer.

Caught another case of this:

I guess it's not particularly useful in this case anyway.

Oh, that hint only shows for accepted revisions right now.

Do they actually have dependencies declared? Any idea why the screenshot doesn't show the "Open Dependencies" marker visible here?

This would be nice to have but is somewhat involved:

From reviewing the code, it appears that this should be handled correctly already.

Presuming resolved until we hear otherwise.

Someone in IRC hit this on stable and I haven't seen more reports on master, so I'm going to bring the changes over.

See also T4947 for some discussion of SELinux.

I believe this is now fixed in HEAD of master. Let us know if you're still seeing issues.

We also say "Only supports JIRA 6" but that means "JIRA 6 or newer", since JIRA 7 works fine.

Let me take a shot at it locally first, I don't immediately see a real way that D16494 could have fixed this given your repro steps.

(I'd be a little surprised if it was and it still merits a real fix even if it doesn't happen in practice anymore.)

There is a small possibility that this was "fixed" by D16494 on Sep 5.

I believe all that stuff is fixed in HEAD of master, let us know if you're still seeing issues (other than text not being searchable: it isn't currently supported). Thanks for the report!

• text does not support searching, and does not claim to support searching (e.g., is not listed on "Constraints"). The intent is to eventually expose fulltext/content search here rather than exact-match search.
• We did not validate constraint keys, so it would appear that we might support searching on invalid constraints. D16507 fixes this: we now throw an explicit exception pointing at the error.
• link does support searching, but did not handle query constraints correctly. D16508 fixes this, and it now should apply these constraints properly.

Presuming this is resolved, but let us know if you're still having troulbe.

Presuming this is resolved, let us know if that isn't the case.

I believe this is fixed in HEAD of master. Update libphutil (by running git pull in libphutil/) and let us know if you're still seeing issues?

I think I broke this in D16504, I'll fix it shortly.

Changes associated with T11592 probably fix this in practice. The new behavior is transparent: subprocesses get SIGTERM at the timeout, and SIGKILL a little while later if they fail to exit.

We can just query that as a setup check, although I don't recall too many issues with it recently.

Oh, this isn't expected to work. These don't currently expose a constraint. You can find an exhaustive list of constraints in the "Custom Query Constraints" table on the API page, and no constraint will be listed for these fields.

(The $profile object is a PhabricatorRegistrationProfile and has a few other methods available.)

This is possible today, although only via the older events API:

I believe this is fixed in HEAD of master now. Let me know if things look good on your end and I'll cherry-pick the fixes to stable?

I cherry-picked those fixes to stable, created a test instance (test-on6dfrmgkt7t), uploaded a 100KB file which went to S3, exported the instance, and got a clean export with the file data retained on the instance.

To this use case more broadly, Spaces is the best tool we have today but may not be a perfect solution. From elsewhere, here's general thinking on this today (this was originally a response to a request about T8442):

We've iterated through a few versions of instruction lengths without much luck, and an older version of the form had a bit more text upfront but didn't seem to have any impact.

We haven't received more information about this in more than a month.

My goal is to fix this process so that we don't have to go through it over and over and over again.

Even if you don't make it to Describing Root Problems and miss the huge red header in Contributing Feature Requests, that document has a large amount of text with the same message:

Here's my general plan of attack here:

This will be fixed when Differential moves to EditEngine, covered by T11114. I'm going to merge this there.

Here's roughly the request we would have liked to see instead of the request you actually filed:

How common is it that a developer is only allowed to see company A, and not see company B? Is this common, or can most employees see all or almost all of the information about companies and you mostly want to prevent employees of company A from seeing information about company B and vice versa?