Problem: Overwhelming lists of (assigned) tasks steal focus.

Confirmed by updating to the latest, thanks again!

Awesome, thanks for the quick fix!

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

Also, if you just want to look at a subset of tasks you can always create a query panel using flags on your dashboard and flag the tasks you care about. I've been doing that lately and it feels pretty good to me.

Why are you trying to snooze a task? Why don't you just, you know, do the thing?

I was thinking of adding some code to phabricator to set the phusr cookie for alternate-file-domain (aws cloudfront) when a user login as well in order for me to track user download of software packages in the file application. What is the security risk involve in doing this? Is there a better way of capturing a userid when they download a file being served from a CDN?

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

Sounds good, thanks!

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.

Happy to bring those changes in and test it out. Also happy to test any patches if testing JIRA related stuff is a pain.

(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!

Sorry for the late reply. What an incredibly well written and thoughtful response! Thanks!

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

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.