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?

I was able to reproduce on this install by passing rPf712ae718ccc1c94d882c626ca8626b77346026b to the Herald test console.

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?

The goal is to provide an easy way for us to print messages like this:

Sorry, we never have any idea. See Planning for discussion.

Why shouldn't a developer be a member of a project they are working on?

They will be working on multiple projects.

In this case, we have a new developer and he needs to be added to multiple projects.

I'm going to ask you a series of questions to figure out what your actual root problem is. When we're done, I'd like you to explain why you didn't just describe it in the first place after reading Describing Root Problems, and how we could improve that document so that you would have gone through this process on your own, umprompted, without requiring me to spend time asking you questions instead of improving Phabricator.

You've read that documentation and this request represents a sincere effort to follow the instructions it contains?

Please see Contributing Feature Requests for help submitting a feature request. Thanks!

In PhabricatorApplicationDatasource, do a PhabricatorApplication::isClassInstalledForViewer(...) test on each application and skip it if it is not installed. You can get the class name with get_class($application_object).

I think there's another one of these in DivinerAtomController->composeTasks(). The other getDocblockMetaValue() calls anywhere in the codebase are also suspicious.

Oh man -- I didn't notice that the random test account I was logged in as in Chrome (named wwwuuu) was an administrator. I have a repro.