I'm strongly resistant to that, see T8227.

(That was a race, not me separately correcting the status, if it wasn't obvious.)

Truly, we have closed this task.

That is a cool looking bug.

We do not support disabling Javascript and have no plans to improve Phabricator for users who intentionally disable Javascript. These users should enable Javascript if they want to use Phabricator.

by default, all search terms should be AND'ed instead of OR'ed

For completeness, note that this opens up a sliver of a DNS rebinding SSRF attack window (see T6755 and T6755#103700 in particular).

Before I forget:

Adjacent work:

Various notes from prototyping:

T10586 is likely a second case (similar to T7248) of a user without mysql or mysqli.

T9640 is tracking PHP7 compatibility. We haven't extensively tested Phabricator on PHP7 yet, but I believe several users are running it without any issues. We're happy to fix issues you encounter with PHP7 if you report them.

Is that output from the version of PHP with a problem, or from PHP 5.6.17?

You should be able to do "Visible To: Members of X" already (or use Spaces, even). Tags wouldn't affect visibility.

(I think that title edit is accurate, let me know if I misunderstood.)

@asteinlein, sorry, I missed your earlier question.

This probably isn't directly related to PHP7.

Can you show me the output of this command on your system?

It took 6 months before I got my first patch accepted in gerrit.

Maybe notable is that these use cases seem to be completely different from the use cases discussed in D14104 (where "lightweight diffs are probably a plurality, if not majority"). There is also some possible overlap with T6008.

Here's a general outline of a workflow which might satisfy everything without creating the "stomp all over new hires" tension that I want to avoid:

Here's my best effort to summarize downstream use cases for this by reading through https://phabricator.wikimedia.org/T121751 -- let me know if I'm misunderstanding, missing, or misrepresenting anything:

To provide some background and context, we added Commandeer in D2257 to deal with use cases like this:

Yep, that works. I didn't realize that null was a possible return value.

This isn't a bug, there are just no fields available.

I didn't purge the cache here, but here's an updated version of the original diff without the rendering error:

(I did half a diff on tags-on-credentials yesterday but Passphrase uses a couple of unique elements (like a "password" control) that don't currently have field support in EditEngine, so conversion wasn't entirely straightfoward.)

His reply was sent to everyone on this task (you, me, and himself).

This is made difficult by the nature of dragging cards into sorted positions on workboards: if you drag a card between a 5-point task and an 11-point task, we need to give it some number of points between 5 and 11, break the sort order of the column, or fling the card to the correct position in the column, which may be offscreen. Currently, in the simpler case of priority sorts, users don't seem to expect any of these behaviors, and all of these interactions are confusing to some users (today, we change priority).

Thanks, that test case was very helpful.

In T10575#164647, @alawson wrote:

Being rude isn't a good way to attract people to a product.

or through Pholio

This one's slightly trickier than T10570 because leading whitespace is semantic in lists.

Thanks for the feature request! This feature request doesn't have the information we need to move forward, so I'd like to start by trying to understand why it doesn't. Specifically, it does not describe the root problem you are facing, and instead asks for a specific feature.

Ah, you're right, thanks! I misread that page -- that does make Mercurial tags a lot easier to deal with.

Make it possible to add "subproject columns" in the parent's workboard

What version is libphutil at? This function was introduced in 821cad81.

Yeah, persistent details would be helpful. My best guess at repro steps from the screenshot is:

It needs a pile o' JS since it needs to change as you drag stuff around, but we can start with that.

I'm going to close this since there's no pathway forward that I can see. We might just not understand your request.

I slightly miss the card counts too, since we have points enabled on this install but don't really use them.

I'm going to write a CurtainExtension for it (I just missed it in the original round) but you might have to fix my bad stylin'.

I'll leave this open for now since the behavior still feels a bit spooky to me, let me know how things go once you get the key in place? If they're smooth, we can chalk this up to be being bad at MySQL.

I suppose the originally proposed key may be better than I think. I was imagining that it couldn't use the third part of the key (on changeType) but I suppose it actually can. I'm still confused by the UNION ALL behavior, but if the key's working on your dataset I think it's fine to add it -- it takes <1 second to add to our dataset, so even for large datasets it shouldn't be wildly unreasonable, even if we do find a better key later.

I'm seeing a replay of the (current?) rules about this message?

That's fine -- it looks like it's picking up the keys, I'm just not sure why it's then examining 303 million rows when it has the keys available.