Is it possible that you didn't restart Apache (or PHP-FPM, if running nginx + php-fpm) and the old code is stuck in APC?

Yeah, real apps might be overkill for this.

Nope, sorry.

We have this; I'm not sure if it's helpful or not (not much specifically about search filters):

One of the subscribers (person A) accidentally replies-to-all with a comment. This sends two emails -- the first is from:A, to:phabricator, cc:subscribers, and the second (a few minutes later) is from:phabricator to:subscribers.

In T7447#111476, @avivey wrote:

Also, I'm missing a button to "see comment in original context", in cases where the current context is confusing.

Fold “Done” comments only. Leave “Not Done” open.

Hmm, okay. I'll take another look at this and see if I can reproduce it.

Now that PhabricatorApplicationConfigurationPanel is modular, I'm inclined to do this:

Are those processes old, from before your most recent restart? (e.g., "STARTED" column in ps auxwww) I think <defunct> usually indicates that the process is not in good shape. Maybe try this:

There's no way to limit the number of processes, no. What are the processes you're still seeing? We shouldn't generally be running the same hg log command anymore, so it would be surprising to me if you're seeing a smaller number of very similar processes.

With autoscaling pools and reduced overseer memory requirements this is probably indirectly fixed -- phd start is ~3x less memory hungry or something in that vein. Haven't seen any more reports of it recently.

Presuming this is fixed since no one's yelling, but let us know if you're still seeing issues.

They have canUseInPanelContext() now so I think this got fixed somewhere.

"Older Comment" no longer exists at HEAD. Please see T7447 for discussion of this feature.

I'm just going to kill this under the "no bug reports on prototypes" rule since I imagine we'll fix it the next time Phragment gets touched and Phragment has one trillion other problems.

I don't understand what this is asking for. You can build a panel which shows open tasks you are subscribed to like this:

Are people who have had chance to use the auto-folding inlines finding that they're an improvement?

See discussion in T7447.

I'm just going to merge this into T5955 -- this is going to become:

Hmm, I'm not sure then. It doesn't look like it's producing that much output, either ("... (10,110 more bytes) ..."), so I can't imagine it's any sort of resource exhaustion or OOM-killer kind of issue.

I'm just not sure what the expected behavior is if there are multiple valid addresses (I'd say: reject the mail, but maybe that's not what anyone else would expect).

I think we should possibly make an exception for creating objects -- for normal replies on existing objects you get two copies of basically the same mail, but for creating objects you're losing out on the link to the created object. But we're going to hit this again soon in Calendar and can take another look at it then.

Access is automatically set to require access to the containing repository if Phabricator knows about the repository (use arc which to check).

ScriptAndRegexLinter needs to be modernized, but is strictly more powerful than the proposed linter. Something like this will implement your desired lint rule after the linter modernizes:

I think it's reasonable to always let administrators disable files they can see. We don't run into any problems by supporting that and it makes cleanup a bit easier for a reasonable set of low-sophistication attacks / nuisance users (disable the user and then disable the l33t w4r3z they uploaded).

Closing for lack of feedback. See also T7674.

We don't have enough information to reproduce this problem.

T7908 is somewhat similar.

I think the HGTEST repo works now.

I think this is fixed now. In particular, the behavior today would be:

This has been in HEAD for about a month and we haven't seen any other installs reporting issues with it. If it's still causing problems, you could disable it locally like this until inbound mail gets set up:

Another possible attack on this is Phurl (T6049), a planned URL shortener application, which has the U monogram. We'll probably support named URLs (e.g., https://your.install.com/u/corp can be a named short URL which takes you to the corporate site or whatever) and we could reasonably let Phurl URLs also resolve into objects (i.e., store "the object D123" instead of "the URL http://x.y/z"). Maybe named short URLs end up with a monogram like U/corp (generically, they'd be U/8anf1X for randomly-assigned short URLs) and perhaps that covers things.

We haven't seen other requests for this and it doesn't seem very valuable to most installs. The definition of "inactive" is also subjective, and seems likely to vary from one user to another.

We haven't seen other requests for this and it doesn't seem likely to be especially valuable to very many installs. As a workaround, you could perhaps use a task or conpherence room to collect join requests instead ("comment on this task if you want to be added to project X" + link to the task in the project description).

In T8044#111257, @eadler wrote:

I want to be able to see every user that has access to my phabricator install.

Does this command work properly when run from /var/repo/XYZ, where 'XYZ' is the repository callsign?

This use case is very far outside the mainstream and not a good fit for the upstream.

T6560 is essentially the same issue, but specifically with tabbed panels.

T8034 is half of the "similar, less-severe" issue I mention above.

Easiest fix is probably for files in /__tests__/ directories to not trigger inclusion of other files. I think it's reasonable in the general case that if you only touched /__tests__/x.php, we only run that file, rather than doing the full cascade into all adjacent/parent tests.

What problem are you trying to solve?

I think (2) is the right way to go so I kicked this into T5378. I'd maybe still render them as URLs but they should definitely trigger mentions.

I think the original proposal was to make the panel disappear. This isn't something we'd be likely to implement, for the reasons @chad gave: it's super confusing and doesn't give users any tools to understand the behavior.

Yeah, I think you have to write a bit of JS since every other menu we have either gets generated via JS or has at least one item in it that needs JS.

the svn / no svn issue should be fixed

For (1), what output do you expect?

such mentions

I can't reproduce it either, including on Firefox/OSX.

prevents typing "tea time", not acceptable