We are vanishingly unlikely to pursue this naturally. It is very complex and we do not consider it valuable. We have never seen similar requests from other installs, and this UI seems far worse for most users because it makes discovery difficult.

We can resolve this by parsing the query and rewriting the query we submit to the engine as "+x +y" if ft_boolean_syntax has not been adjusted.

Hmm... maybe I'm not explaining my expectation well, but the "issue" I'm referring to is the fact that after steps (1)-(3) I now have a task that is in the "Subproject A" column in my "Project X" workboard but is not *actually* in Subproject A anymore.

These fields don't apply to other document types, and other document types have other fields which do apply to these results. It does not make sense to search all documents by, e.g., "Priorities". We definitely aren't going to pursue this as described.

One final note, re: 2(b) which is the only item for which I did not file a new task, as you know, most people leave most defaults the same (when I was on the Gmail team it was 80-95% of people depending on the item). I'm hopeful that items like this could have defaults that are more common for the most common phabricator use case. I'm not an expert on what that most common use case is, but my gut is that is would be mostly Maniphest for software development, hence the suggestion.

Hi all, glad to see this issue is being looked at. Per my task in T10641, simply having "all documents" search show the same style of content as is seen in Maniphest search would speed up our day to day, as most people on our team use all documents search (unintentionally, as it is the default), even though all they really care about is Maniphest, and so their experience isn't great here (their impression is "Phabricator search isn't good" which I think is related not to functionality but discoverability and smarter default configurations).

@chad understood - I reviewed https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ - was very informative, thanks! I also commented on T8660.

Per conversation in T10589, I would like to echo @jhurwitz's request. In reality, both search for open & closed and open-only are use cases that exist. But in day-to-day work, even for QA, the very significant majority of use cases is for open only. In addition, w.r.t. the "closed tasks also" use case, the user behavior in response to "I didn't find what I looked for" is "refine my query" which is a natural human behavior that will cause these users to discover "oh, closed isn't checked". In addition, there is a visual cue when they see closed tasks that closed tasks look different, so the anticipated concern of "maybe the person searching will give up not seeing their closed item in the list" I believe is negligible (especially in face of the much more abundant concern of "omg there is so much closed stuff here...oh yeah, I need to ensure "open" is checked and "closed" is unchecked).

T10486 is related; T6027 and T5214 are somewhat related.

Thanks for looking @chad

Nothing actionable here, since we don't plan on adding additional options.

Does the task go away from the workboard when you refresh? I think that's the missing step here, that you're editing the task on the workboard.

I followed steps listed here but didn't get your same outcome. Can you clarify the steps to reproduce, the expected result, and the version of Phabricator you're using.

I see you already found an existing issue, sorry for the noise.

We don't keep this install at HEAD at all times

I understand, I didn't think this was the case anyway. I just figured I'd let this issue be known so it will at least be fixed.

No problem. We don't keep this install at HEAD at all times, for what it's worth.

We personally are not on any version with the new layout, so I can't say it fixes it.
I just drive-by reported a bug I saw on this instance.

Version information is required for bug reports, as is updating before you file a bug report.

(Nearly every text area in Phabricator can take files via drag and drop.)

This doesn't appear to be a Bug Report

Thank you both for clarifications. Will follow your advice.

Can you fix the issue with arcanist in near time, that arcanist does not accept milestones at differential diffs? This is very annoying.

Indeed. Sounds like I just need T5873 then. Thanks.

for anyone else that runs into this in the future: http://www.gossamer-threads.com/lists/wiki/mediawiki-cvs/626638

T7190 has discussion of a similar case.

I think this isn't tremendously important for Countdown but should definitely be sorted out before we unbeta Calendar.

It might not be bad to always show timezones in email explicitly to deal with cases related to T3025 better (e.g., you fly to the east coast for a conference, get prompted to reconcile your timezone after T3025, and it may not be obvious that this also affects mail you receive until you return and re-reconicle back to PST).

With metamta.one-mail-per-recipient on, we can adjust this to the viewer's preferences.

@epriestley Any idea why the issue in my previous comment would be happening? Thanks.

Unfortunately we can't take bug reports missing required information. Specifically:

Visit /config/module/versions on your install. If it does not exist, you're not running HEAD.

@richardvanvelzen Thank you for your comment. However, I don't have /config/module/versions/ or any Phabricator-related versions file or directory, for that matter, on my system. If you meant /conf/, then this directory contains only the files __init_conf__.php, keys and local. Please clarify.

• You can obtain the versions at /config/module/versions/ on your install
• The max nesting level is set to PHP_INT_MAX (see libphutil/scripts/__init_script__.php:44), so you should never see this error.

Evan basically answered my question in T5214. There are good reasons not to expose an API at this point, as due to possible future changes, it might be unstable. I'll try to figure out how to do these things within Phab only, perhaps by creating myself a temporary outdated-style API. Then I'll to understand the second bullet point above more fully. I'm pretty comfortable I understand the point made about EditEngine.

In T9987#166027, @aleb wrote:

Why is the list of diffs in a task page ordered by creation time?

Why is the list of diffs in a task page ordered by creation time?

@ofbeaton, if you care also about starting a translation, you can do it for src/applications like this :
./bin/i18n extract src/applications and ./bin/i18n extract src/view and merge the results.

I also may just restore this at some point to align with user expectation, even though I think it's a bad feature and we benefited on the balance from removing it.

T1258 might be another attack on this, not sure how much that overlaps things.

In T10623#166012, @epriestley wrote:

We have a large, and growing, set of teams that would like to get CCed whenever a review is created in a repository they work in.

Would something like adding "Watch Repository", like "Watch Project", so users could get CC'd on every commit and revision for a given repository possibly be a better solution for this?

Understood. Thanks for the information.

We have a large, and growing, set of teams that would like to get CCed whenever a review is created in a repository they work in.

In T10628#166000, @richardvanvelzen wrote:

FWIW, I've pretty much never looked at "Open Revisions Affecting These Files", and only look at "Local Commits" to check if the parent commit is already pushed.

In T10623#165958, @epriestley wrote:

Can you describe the root problem? What kind of rules are these? Revision rules?

I filed this primarily to ensure there would be task in the upstream. I fully expect this to rely on T10329 (and believe I even commented in that task).

In T10621#165969, @epriestley wrote:

How do you imagine Phabricator learning about the existence of new external groups? Just polling a list of every group in LDAP every hour or whatever?

Yeah, pretty much the same for me. I believe "Open Revisions" has a small population of fans and "Local Commits" may get more useful eventually (e.g., after whatever happens with T1508) but I think we're on fairly firm ground shoving these into tabs.