@epriestley: thanks for the thorough consideration.

Far future I'll show u m8

We should probably have it to fix T8135 anyway, I was just planning to cheat through that but definitely can't cheat through "Group By: Assignee".

oh. sorry. :(

I've spent about 8 hours on this today and made nearly zero progress.

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.

Oh, also in the mock, I had let people set the "noun" for whatever their points were. Which could then be surfaced wherever.

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

points/currency/time are the main things I think people would try to track in a point field

well maybe I'll allow fractional points

Here's my current plan:

This probably still isn't perfect, but:

I often want to know when the last comment was on a task and who made it. This is a shortcut for digging through my emails; I want to be able to check boards and see if tasks have activity since I last touched them. Any chance of something like this making it in as an option?

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.

Given all the refactoring, is this still relevant?

We may have implemented this at HEAD. Kinda bare bones, but pretty!

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.

On the Wikimedia side, looking at https://phabricator.wikimedia.org/T1178, I see almost no support or consensus for this feature. Restricting open editing is in some ways antithetical to Wikimedia's values (we try to be as open as possible) and there are a lot of other issues with Phabricator that are higher priority for us.

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

In T6502#157400, @epriestley wrote:

This is probably happening tomorrow, unless I am just toying with everyone's emotions.

This is probably happening tomorrow, unless I am just toying with everyone's emotions.

Looks great, thanks for the quick turn-around!

Hows this:

Yeah, I suspect that the length of the header is the issue.

If that's the case, a workaround is to query for the tasks in Maniphest with page size > 865 instead, then "Select All" and "Batch Edit Selected".

Oh, maybe the issue is actually the redirect. Specifically, we'll end up issuing this:

I can't immediately reproduce this by issuing a query for 1,000 tasks, then doing "Select All > Batch Edit Selected". The page takes a couple seconds, but loads fine.

Well I don't choose any tasks, I guess it defaults to all objects visible on the workboard (of which there are 865).