We could lock this order into "drag to column" interactions only once those are built (i.e., not support "drag to position" -- basically, when you drop a card, we fling it into the correct position, even if that position is at the bottom of the column far off the screen). This will be somewhat confusing but maybe the least-bad of the options.

After D20229, the rules are:

We have no customer interest in this and no current plans to pursue it.

However, at some point I expect that we'll be unable to continue meaningfully improving the heuristic in general, and need to start adding rules based on the file language (for example, look for function signatures in C, keywords like "function" and "class" in PHP, patterns like ".prototype" in Javascript, lots of opening braces in Lisp, etc).

I think this is reasonably well-covered between arc anoid and arc weld. Once T5055 comes online, third-parties can presumably fill in more titles for the arc game library.

These have existed for a while and recently got support for customizing sub-object behaviors in 2018 Week 50 (Mid December) and are being extended to Projects in 2019 Week 5, so it looks like they're here to stay.

D19968 got us closer here, but the link targets aren't actually rendering properly.

I'm not confident there's really a path forward here even for the subset of mailers where we have full control of the SMTP envelope and can generate Message-IDs, which is only a small subset of mailers today. Even if it does work, it makes the "Reply All" problem worse.

...it is virtually inconceivable to me that this is something we would ever bring upstream in any form.

@amckinley, for general context on where I'm headed here:

This doesn't seem to be cropping up terribly often and I think this use case is fairly weak.

This might happen eventually, or as a side effect of T7303, but the use case here is pretty narrow and there's currently no customer interest so I don't currently anticipate building it.

Password management is in good shape after T13043 , and this would now be fairly easy to implement in a general way by adding a check in PhabricatorAuthPasswordEngine->isUniquePassword().

In T12588#242719, @epriestley wrote:

If any of these lists only have one form (or the user can only see one form), we'll take the user directly to the specified form.

When users click "Create Subtask", we now look for a list of possible subtask forms.

@epriestley we are using the "menu item" solution that you described above, and the primary remaining pain point is that when you click on a link, the menu highlights "workboard", which confuses some users, because they expect the link (i.e. the menu item they just clicked on) to be highlighted.

This currently appears to be mooted by T13188.

After D19615, callers to harbormaster.sendmessage can specify "format": "remarkup" to get "details" rendered as remarkup (including {Fxxx}) instead of plain text.

I expect to add flags like "this doesn't block undrafting" and "this build doesn't matter" soon, and then possibly refine those. I'd consider revisiting this after those deploy, but am not excited about formalizing the idea of "only some of your tests failed so it's okay" or adding a check for each build (since this won't scale very far). The tooltip is reasonable but I'll just turn that into a note on T13088.

(Feature request with no support mana and no discussion.)

We don't have any support mana behind this request, it's a good candidate for third-party development, and there's no unique information in this task so I'm just going to close it out.

Bumping this just to say that another team I work with wants to track WIP using count instead of points. In their case, they are a support team, so their board is populated by cross-tagging tasks that belong to other teams. When those cross-tag tasks have story points for the team that originated the task, the story points show on the support team, as well. This means that the support team can't default the story points to 1 just to get the count in WIP.

Back when this was originally reported, I'm pretty sure git lfs clone didn't exist (or at least I wasn't aware of it's existence). The appropriate fix now is probably different to the fix suggested in the original report.

We have a similar issue - however I think the "fix" is probably worse then the workaround.

This is well-suited to a third-party extension, particularly after T5055.

I don't currently plan to pursue this.

I don't currently plan to pursue this.

I don't currently plan to pursue this.

Hey we actually have the same issue-- folks on the team would like to edit "owning team" from within the action menu. The problem with having to edit the task is that the UI for task editing is less discoverable and requires more clicks than the action menu -- folks are used to being able to accomplish what they need from the action menu so it frustrates them when they can't. This isn't a blocking impediment to our workflows or anything but it would be a nice-to-have UI improvement.

okay. thanks!

See Planning.

Hello @epriestley, could you please provide any update on this task?
Won'tFix or InQueue ?

Yeah, that was the commit that reminded me how I wanted this. Unfortunately, it looks like the database still stores literal repositoryPHIDs, so the schema would need to change if it were to handle functions (which is why I bumped the ticket instead of taking a stab at implementing it myself first). I figured I'd add my voice to the ticket for now and continue toiling along with complex Herald rules for now.

After D19191 it would be relatively easy to support projects and wildcard functions (like "Any Repository") but there's currently no interest in this from customers.

I don't suppose there's been any interest in adding wildcards/function matchers to Owners in the last couple of years?

New, far wordier options available at HEAD:

Resolved by D19163 etc., see T13088.