The rest of this will roll up into other tasks which actually use it, etc.

Yeah, I'm planning to let you label the field with whatever you want, I just haven't figured out where I'm going to stick that. Current leading contender is adding some special stuff to maniphest.custom-field-definitions, but I don't love that for various reasons. I may just do some new maniphest.points sort of thing and put some UI on it.

Yeah, fractional points are OK if you're literally labeling the field "Estimated Hours".

well maybe I'll allow fractional points

Here's my current plan:

Cool, sounds good. There's definitely room for improvement here and we're open to making changes if it turns out you do actually have a few competing use cases to balance, but I suspect you can make reasonable headway on at least some of this by revisiting Config with an eye to dialing settings back toward optimizing the "ignore / review" decision.

This probably still isn't perfect, but:

Using PHIDs instead of slugs is likely a workaround, but possibly not helpful depending on what you're doing. D15214 should fix the root issue. Thanks for the report!

Never mind, here's an example:

Can you give me an example of a URL which hits this?

Yeah, it feels a bit like the "baby's first typeahead" button to me (since it didn't exist for so long, and is usually useless if you know what you're going to select) and it usually takes me a minute to remember it's there.

Here's a workaround:

You can use a policy like this to restrict a key to requests originating from a particular VPC:

I believe we generally have an acceptable way forward here, at least in broad strokes, now so I'm going to close this out since I think it has served its purpose, but feel free to file a followup if things stall or you run into trouble.

This isn't necessarily "won't ever fix", but the cost to secure SVG sufficiently is enormous and I can't imagine it making sense to pursue until we are a huge organization with as many as 4 or 5 full time engineers.

Looking through the security situation in more detail in response to a recent report via HackerOne, I think it's unlikely that we'll pursue support for this in the upstream. Browsers will execute Javascript and other dangerous actions (external includes, entity expansion) in SVGs, and there is no way to avoid this in a categorical way or otherise delegate security to the browser.

Resolved by D15207. Thanks!

The problem is that it means a card may appear more than once on a workboard (in multiple subproject columns) which violates a lot of assumptions the code makes and will probably be confusing to users forever. We technically generate these columns today, they're just hidden at the last second to avoid obvious brokenness in the UI.

We have some plans to explore other approaches to "view with comments". I think that's probably the right action overall, and the new edit treatment feels good to me.

The dimmed state is pretty obvious to my eye (it has possibly changed since this was originally filed) and we haven't seen feedback from other installs about this being difficult to parse visually. If we did see more feedback in this vein, I'd want to start by making the dimmed state more aggressive.

Yes, in theory -- this is a problem with assigning sub-priorities as a side effect of dragging cards around on a priority-ordered workboard. That code hasn't been touched.

You're basically just asking for a magic chart feature that does whatever you want. We, bound by earthly constraints, can not build that, and the request itself is not specific enough to be helpful in defining product direction. See also T4171.

Some day we'll provide some kind of tooling or migration approach here, but this seems stable for now.

I haven't fully decided yet.

(Maybe the hybrid bar would be useful in some far-future PM-manager-manager view or whatever.)

If we're requiring setup and active management before we show a bar, maybe this bar is better?

Ah, so you wouldn't even show this bar until we implement points?

As a general philosophical question, what actionable information are we trying to convey with this element? I think it looks good and is probably worth adding even if it's just a "pretty bauble", and it's nice because it can show something reasonable and immediately comprehensible without any additional configuration/setup, but we're starting to descend the slippery slope of charts and graphs and I'd really like to be armed with strong product rationale as we proceed.

I'm also 90% sure I'm going to have to build a PHUIX / pure javascript version of this anyway, so the pretty photoshop pixels are probably more important than the specific markup.

Minor, but it would be nice support multiple color segments, e.g.:

Given the feedback from @Krenair / @MZMcBride, I'm going to shelve this for the time being since WMF is the major driver for it but it looks like some mixture of contentious/low-priority/hypothetical, and even if consensus/priority does develop from WMF I'd like to wait for EditEngine and make sure the problems survive the new capabilities it introduced.

(Oh, the WMF task got a similar token so it's presumably an objection to the control.)

I'm not sure if that thumbs-down is an objection to introducing this policy control or an objection to my hesitance to introduce this policy control.

Looking deeper, I'm sort of wondering if we actually need this. Are you seeing (or still seeing) issues with this?

I'm just going to merge this into T10010 and note it explicitly as errata; I'm planning to do this but just haven't built a hide-menu-item feature yet.

Thanks for catching this!