Oh, that probably didn't get updated for the new IconSet stuff.

Seeing as how you don't need to select a result for the mention to work, the inability to get the typeahead results back after dismissing them isn't that big of a deal either way, imo.

(1) is currently intentional -- I'm being pretty aggressive about throwing the prompt away, and dismiss it if you use "up" or "down" to get off the ends of the list, under the assumption those actions mean "throw this away, I hate it". I'm definitely open to changing those to just eat the inputs.

Ok, here's what just happened on my initial test run:

One thing I've done differently than, e.g., Facebook is that I've made summoning the completer explicit (when you type "@" or "#"), not implicit (when you position your cursor somewhere in something that looks like a username in the text).

(This seems to work really well for me, btw)

I heard @scp is also good at breaking things.

I can't break it with 30 seconds of attempt. Wonder what @joshuaspence will find.

That appears to be working better, now.

I think my analysis of the blur thing wasn't quite right, I'm still getting intermittent success with clicking results. I'll dig into that a bit more.

derp

In T10163#154221, @chad wrote:

If I type @demo and then tab it changes to @abuna

If I type @demo and then tab it changes to @abuna

I'm going to call this resolved and move errata to T10163, since I assume most people on this task mostly just wanted to know when the feature landed.

This is now live on this install.

In T1279#42118, @epriestley wrote:

• Ad-Hoc Blocking Reviewers: There's no way to add blocking reviewers from Differential or the CLI (T731). Despite some user interest, I still have a hard time understanding the need for voluntarily adding blocking reviewers.

Nuance is the other product, but no ETA on that. It's a layer above Maniphest that sits as a queue before things come into the system. With it, you could segment engineers working better from average users (since they could only open up Nuance tasks).

I've merged this over, feel free to add additional thoughts or use cases on the other task. We know this is missing in general, I don't think we have an immediate solution though, maybe @epriestley does magically. We are actively working on Projects v3, so it's on a more immediate radar.

Indeed... that was sure buried in there. Is there some task open for consideration of that that I can track? This is a miserable daily activity for me going through and making sure people opened their tasks right.

I don't know how to resolve conflicts, for instance with a Column that has specific edit policies form attached - what happens when you drag other tasks in and out of those columns?

This is just T10004 (the lack of workboard support is noted for future).

It could be that what you actually want is Nuance,

Let me try again.

It could be that what you actually want is Nuance, our help desk tool, for instance, if you're using Columns for triage and routing for security or policy reasons.

It'd help us! See Describing Root Problems for a better description of what we look for.

Is that a way of asking for additional problem statement text?

Yeah, we really need feature requests to state problems people are running into actually using Phabricator day to day. Anticipated problems or problems that exist in theory or "it'd be cool if" don't help us understand real world use and how to fit your problems into everyone else's problems.

You need or we need? Phabricator should only require one individual from the Blocking Reviewer project to satisfy the accept condition.

I gonna need all the blocking reviewer to accept the revision.

OK Chad, but if I add a specific blocking reviewer, another reviewer will be able to accept the revision but this one will stay in status "need review".
And if I add all the members of the code review committee as blocking reviewer, I gonna need all the blocking reviewer to accept the revision.
I'm sorry if my original message was not enough clear.

How doesn't blocking reviewer solve the problem. If only certain people can truly accept a revision, that's the correct feature to use.

Yes I'm already subscribed to T4887 but I don't want to add a "blocking reviewer" as any member of the code review committee can accept the revision. And the task T731 is great but is complementary to what I'm asking. The case I describe is not covered by T731.

T4887 and T731 likely fully overlap with this request.

Can you just use a blocking review for the people who can truly accept revisions?

T10161 is a case of another install that selected ElasticSearch without a specific reason, based on a general belief that it is better in some intangible way.

See some general discussion in T9893, although this doesn't seem to be an ElasticSearch 2.0 issue.

I am using elasticsearch:1.7.4 docker image. We thought using elasticsearch has advantages over mysql fulltext, is that wrong?

(I've made a private note about this elsewhere, if you work with @nipunn.)

Just closing this since it's a huge fishing expedition that we can't help with, see Contributing Bug Reports and Support Resources.

The workflow I used when introducing linting was:

• Temporarily enable a large/default sent of rules, run with --everything and get the lay of the land, maybe make a list of common errors or get a list of all options from the linter itself
• Decided that rule X looked reasonable ("no trailing whitespace" or something like that)
• Send a diff out for review that fixed X and enabled the X linter rule
• Repeat.

(Also: why are you using ElasticSearch instead of the default search?)

What version of ElasticSearch are you using?

@epriestley, Thanks, of course, adding any file to the next commit solves the problem.
By the way, it is a not a high priority bug since it does not broke the interface.

Sure.

Can you explain this problem in more detail? See Describing Root Problems.

Thanks, those reproduction instructions are clear and I expect it will be straightforward for us to reproduce and fix this.

Initialization Error Pull of 'rMOBILE' failed: Command failed with error #1! COMMAND git clone --bare -- 'xxxxx' '/var/repo/MOBILE' STDOUT (empty) STDERR Cloning into bare repository '/var/repo/MOBILE'... /private/var/repo/MOBILE: Permission denied

@wakes, Yes I'm reproducing the issue on a local install.
Here is the configuration:
Distrib:

Centos7-64

Yeah -- we may be able to cheat a bit on usernames (although "@Evan Priestley" should also work), but can't cheat on project completion with # since #build more pylons and #build more supply depots should retrieve different results despite having a shared, multi-word prefix.

Oh hi @chad! Er, wait, I don't get any autocomplete love over here so I can't judge it one way or the other.

Have typeahead autocomplete @epriestley despite what the user types~

Mostly, users have a huge number of ways to interact with text: cursor keys, mouse, home/end keys, keystrokes like Ctrl+A and Ctrl+E, cut, paste, all the mouse-driven varieties of cut/paste, context menu actions like spelling correct, shift + everything listed so far to select stuff, dragging selected text, and multi-keystroke character input for non-latin languages. Javascript provides only indirect ways to guess how the user has performed mutations of the textarea, so we have to reconstruct and/or guess about a lot of behavior.