Thanks for the pointer!

Yes it is solved!

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?

Yes my client system is Windows, while server hosting Phabricator is CentOS

No, I downloaded the non thread safe php version from official site.

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

Is your system Windows?

Honestly never seen these functions not included with any PHP distribution.

Did you compile or build PHP yourself manually?

PHP 5.6.13 (cli) (built: Sep 3 2015 15:14:39)

What version of PHP are you running?

I just noticed that D229 is not actually a valid Differential Id.
It is the number of the associated Diff.

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.

maybe also DB's max_connections?

(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):

In T11597#193660, @epriestley wrote:

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.

The most extreme version of this is documented in T11095, where a short-lived form only said "it costs $1,500 to submit this form" and the very first person to submit it didn't read that. See T11095#178732 for what that user saw and the task as a whole for what came of it. It's hard to imagine we could make the "root problems" documentation more concise than "Support requests are billed at $1,500/hr."

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.

Thank you for the input, I think we still have room to improve things on our side, like you say - wall of text.

In T11597#193651, @epriestley wrote:

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

The repeated callouts, giant text, etc., are because many, many users do not follow these instructions and we receive many feature requests like this: approximately one line of text asking for a very specific feature, which wastes our time (and the reporter's time!) and suggests that the author did not read any of the documents. This is worse for everyone than if we could get users to just read the documents -- we'd spend way less time on requests and users would get answers faster. Users who file reports like this are hurting the project and hurting themselves.

When we ask how we could fix things, no one claims they had a hard time finding the instructions. Everyone claims they read them and understood them, and everyone says they are clear after the fact. But I still waste a ton of time asking questions to figure out the root problem, essentially following the techniques and discussion already laid out in the documents, and no one has any feedback to improve the process.

One possible explanation is that a significant number of our users are basically lazy jerks who don't respect our time and are possibly even willing to lie about reading documentation to get a worse answer more slowly than if they'd followed the instructions. I don't like this explanation and I'd like to believe we just did a bad job with some of the documentation, but this scenario has played out so many times now without anyone being able to point at what we should improve that I'm having trouble coming up with other explanations.

The current state of affairs is also extremely negative for everyone. It's really frustrating for us, since it wastes a tremendous amount of our time. It's frustrating for users -- when I pointed you at the documentation, it seems like you felt like I'd just dismissed your problem. But we also can't spend two hours doing this kind of question-and-answer walkthrough with every user. We don't have the resources, and "free help with any question no matter how vague and time consuming" isn't a sustainable model.

My company uses Spaces for external companies and it's painless to manage permissions in that manner.

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.

I suppose I could have read it more carefully but at this point I feel like your goal is to make sure I feel bad about it. Again, I'm sorry for wasting your time.

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:

Frankly, my biggest issue when people submit feature requests is all the chaff. But I see how you could want what you're after as far as requests go. I will admit that while I did read the first document and totally missed the second document on root problem description. Given its location in a giant red box, I'm not sure how that happened. I'm sorry for wasting your time.

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:

I solved this for my purposes here. It might be a decent starting point for you: https://github.com/andypoorman/arcanist/commit/f1eb928c462029397fff9a1f1c42122a6d54bc9f

In T11597#193619, @epriestley wrote:

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?

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?

Well, it sounds like what you're getting at is that we're using Phabricator incorrectly.

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

Thanks; that does help (and also disappoint).

@jonah214 If it helps, unlikely to happen in the next 6 months given current prioritization queue. We are actively looking to hire though to widen our engineering throughput.

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

Is there any sense of when this might be worked on? We end up getting "Error Processing Mail (No Receivers)" due to Phabricator being in the CC a few times a week, and it's really annoying.

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

Why shouldn't a developer be a member of a project they are working on? Even if a project is used as a security group for use in the Visible To or Editable By fields in a task or project there might be multiple security groups they need membership to.

They will be working on multiple projects.

They will be working on multiple projects.

In this case, we have a new developer and he needs to be added to 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.

The request doesn't state a core problem, which is required on all feature requests. A core problem is the why of the feature request. See Describing Root Problems if you need a bit more help understanding what we're looking for. We already have thousands of other feature requests, so if you tell us what you're trying to do and why, there may already be another task or another means to accomplish what you want.

In fact, I did read it. I believe I've effectively described the problem. I can't believe that nobody else has this problem nor that the intent of my feature request is unintelligible. Would a more compliant description be: There is no way to add a user to more than one project at a time. Visiting each of 30 projects individually is a waste of time. Or even, more generally, modifying a user's settings for global things like project membership is impossible without visiting each project individually.

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

I guess I'll never know what I did wrong. Thanks for your time.

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).

Turned out the fix above:

prepped.body = prepped.body + '&projectPHIDs=%5B%22' + projectPHID + '%22%5D'

does not really work. What works is this:

import requests

I was looking for similar functionality (publish the state of some external system on a panel) and instead of updating the entire panel I think it would be nice to use Phlux or Paste: