We could also maybe do something ridiculous like assume it's @2x if both dimensions are even, but M1461 has a 2X image with an odd height (1717px!) so that probably won't get us very far ignoring all the false positives for 400x300px images and such.

I think this is reasonable to build as:

Assuming this mode does not exist, the clearest pathway forward is for you or someone else to:

Does RuboCop actually have a mode where it emits errors and replacement text?

There is not, and never will be. Associated projects never affect policies, so there is no possibility to make them start affecting policies. I'm not sure what's unclear about this.

That one might be better to merge here, since it's probably impossible (at least, in the general case) but this talks about some things we can do in the general case.

By design, changing projects never affects policies. See the documentation here:

@jlvillapalos, can you shed some light on why you didn't include that information in the first place or how we could improve the process?

bin/remove destroy gives you a huge scary red skull-and-crossbones ASCII art for good reason, and you're accepting that issues like this may occur when you confirm the prompt.

T10599 asks for column move APIs, which are adjacent to this.

This transaction can only create a task into a column, it can't move a task. That's why the documentation says "Create into a workboard column.".

I don't think we can detect this automatically -- a, say, web-ready PNG from Photoshop generally won't have DPI information, as far as I know.

We are vanishingly unlikely to revisit this decision. If this is important to your organization, you should look into forking the codebase to provide the functionality you are interested in.

You can "Award Token".

We'll consider adding a setup issue if we see other users having issues with this. Previously, we haven't, so we presume users having or uncommenting these blocks in the wild to be very rare.

Interesting (and weird). Thanks for the update -- and good luck figuring things out.

I'm not immediately able to get --create to bring up a template with "Differential Revision". Here's what I tried:

I think we should ideally try to be more clear about the issue when the user passes --create, even if something in range says "Differential Revision: Whatever". That said "a little bit before I look at it" has been like two years now. Let me spend like 5 minutes on it and if it's a big mess we can just write it off.

The issue you're experiencing is because you're out of date.

In some cases, the effects of the theater can be mitigated issue-by-issue. For example, we may be able to write caching/rendering logic in Javascript to mitigate the performance impact on lightboxes and Pholio. We may be able to attach images directly to email. There may be a workaround for the Safari issue, or we may be able to do preview rendering partially in Javascript. With Quicksand, we can also increase the "hit rate" of client-side Javascript caches, at the cost of additional complexity.

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:

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