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.

Effectively resolved by D19167; see T13088 for followups.

I'm not currently planning to build this, per se. See T13088 / T6139 for lighter-weight support around log summarization.

We haven't seen other interest in this and the use case feels a little unusual (I suspect 15-20% empty documents is very unusual) so I don't plan to implement it at this time.

I don't plan to support this because it makes improvements to milestones which depend on them being ordered ("move to next milestone", automatic date ranges, etc., per above) more complex to implement or use. All use cases here seem to be addressed by "use subprojects instead of milestones", especially after T11036. I'll make the ordering adjustment described above.

I don't currently plan to implement this. I think T5474, T10333, T11036, and using the Maniphest list view with "Group By" address this use case to varying degrees (if you "Group By: Task Status" and then turn your monitor sideways, you pretty much get the desired result). It's possible we'll end up back here in the future, but since I'm not planning to scope this into T13074 I'm going to close it until those changes land and further use cases arise.

Workboards have offered access to multiple task creation forms for some time.

@epriestley Ah okay sorry, I'll do that! But I think the first part is a bug.

Please use the Discourse community forum or your organization's Support Pact to get help with support questions.

My use case for a Webhook: Trigger a stage build when a commit is pushed to an untracked topic branch.

I'm not entirely sure this resolves the original request, but we have webhooks now. See also PHI348 and PHI349. There's some documentation that should publish shortly and the changelog should have more details in the next couple hours.

I'm going to roll this forward into T13069, which discusses remaining work for "mail stamps".

I'm going to merge this into T10448, which exposes this information in an X-Header and optionally in mail bodies.

(I think everything actionable here was addressed, or survives in followups.)

(Future me, see also PHI343.)

The above workaround is not reliable since it skips the files entirely vs checking the remaining characters.

For those visiting from the future via search, I have decided to publish the unofficial patch in a github repo, as it breaks once in awhile due to upstream changes.

I am also interested in this; it's not uncommon that an engineer is testing a regression somewhere and wants to trigger a full CI build of an old revision. Today, their options are (a) have admin access to the Harbormaster Build Plan, which requires a large amount of trust or (b) bother someone who does have admin access to press buttons.

Because of the high degree of complexity there's basically zero chance we'll ever build this without active customer interest, and we have none today. Closing this until interest arises.

transaction.search now returns comments and inlines, including path, line, length, and reply information.

This is either T4675 or T6004. I don't know which will happen first, but I'm just going to close it in favor of those.