Ah, thank you. I'll update to use that.

Broadly, *.search and *.edit endpoint are replacing older *.query and *.variousnameslikeupdate endpoints, see:

It's present in maniphest.search.

I noticed today that the maniphest.points field doesn't appear in the Conduit output for e.g. maniphest.query. I can't find a task addressing this, but it would be very helpful (I have several scripts that used our auxiliary points field, but since migrating that to maniphest.points they don't work any more).

The points in project really look like project tag, I found that a little confusing.

Someone on Facebook noted that I omitted the Cyclone. Eek!

You got all of the mineral costs correct!

In conclusion, we should never add options to the product.

(The difference between the dark and default background colors is so subtle on my monitor that I never noticed it.)

Oh, I do have that set locally -- I thought phui-theme-dark was just the default (since we got rid of light?) but this fixes itself if I switch to, e.g., the red header.

Oh, is this just a dark-theme issue? That seems easy to fix.

We ultimately want teams to choose different colors so they can know which workboard they're on at a quick glance.

Yes, I concur, that would be useful.

My understanding is the feature request would be to set a global color instead of white. If all workboards are red or blue or whatever, I don't think it provides any additional hints. I suspect the use case here is @rphl just really likes a specific color and wants them all that color. Which is cool, but we ultimately want teams to choose different colors so they can know which workboard they're on at a quick glance.

I suspect the goal could be to provide visual hints, in addition to the text, to recognize and disambiguate dashboards.

Why do you want to set a global default background? What is the root problem you're currently encountering?

ehhhhh, this is probably better solved with T7190. I don't think there is much (any?) benefit to a global color, as teams usually want visual indication of which workboard they are on (so differentiation matters).

What is your expectation of what should happen here? This doesn't seem like a Workboard issue, just an issue with menus in general. Should we just automatically close any open ones if you change your mind and open a different one?

No problem, and thanks for including all the relevant version information in your report! Let us know if that doesn't fix the issue for you.

Thanks for the quick reply. Was not able to find that after looking a bit.

This was fixed by 329d036 (Feb 13) which should be available in stable in about 48 hours (or you can update to master before then).

@swisspol that has been implemented :-]

rP080d838c693b by @chad is absolutely amazing. The workboard is way more useful when tasks are tagged with multiple projects. An example: If you head to Workboards , you can see cards having other tags.

Really awesome.

I wish I wasn't using JIRA...

Awesome progress; cover images, points, points graph & project cards rectify just about everything I considered Workboards to be lacking.
Nice one

@epriestley: Yes, I misread the comment and subsequently deleted my response. My apologies.

• Cards also show other projects.
• Workboards can go fullscreen.

@kaldari Most of this ticket is asking for "save priority as the default order" and/or "save 'open tasks' as the default filter" or something similar. Those were implemented by D15260, and are now supported. You can see them in action on this install, and D15260 has a couple of screenshots of the feature.

I had to rename all those junk records just so I could hide them after the fact.

Wow. This is awesome. I'm glad you were able to find and trace down this issue with what minimal info I could provide. I'll try to give better descriptions in the future. It would also be nice to remove columns that have no tickets associated with them.

At HEAD:

In T10346#159072, @robertkraig wrote:

they never existed before when I originally imported their workboards

These are sub projects imported from another project. But they never existed before when I originally imported their workboards. So I was as confused as you to how they suddenly started showing up.

Currently, it's hard from me to tell what's going on in the screenshot. Can you give us any more details on the setup?

This mostly applies to if you're following master. stable is only updated once a week.

We expect people to update Phabricator before filing a bug report. We fix bugs very quickly. Even if you just updated a few hours ago, it's helpful for us to not have to spend time hunting down a bug that was already fixed.

I just updated code early in the day, like 2am.

Specifically, what version of Phabricator are you on? There has been a lot of churn on Workboards this week, and even today. Does this bug exist at HEAD?

how did they get added in the 1st place?

Thank you Evan. I found the reason of the issue.
I'm using your batch file to upgrade and when I run it shows the error below.

If you updated two hours ago, you should be ahead of c2502f1, which is about 50 hours old. We've made about 30 changes between c2502f1 and HEAD, which you can see here:

I updated 2 hours ago. And I have just updated.
The issue is still the same.

Update to HEAD. This was fixed by D15232.

Digging into https://phabricator.wikimedia.org/T76913, I think the actual request there was ultimately not per-board stickiness or per-user stickiness ("the menu remembers the last thing you set it to, and remains set to that if you close and reopen the window"), but an option to save particular filters into the filter menu ("Save a particular filter as 'No Patches Yet' and add it as an option to the filter menu for all users").

That seems reasonable, I filed T10339 to follow up.

A use case: "I want to see how well we're sizing points, show me all 4 point tasks"

These now exist. Enable them with maniphest.points.

I'm think just going to put a "Save Current as Default" or similar at the bottom of the menu (and another one at the bottom of the filter menu) since I think those are sufficient here. Two possible concerns:

I have a vague idea about adding some sort of "addIconAttribute" method eventually, so that we could in theory pass any Task metadata over like how many diffs are attached, if its blocked, pholio mocks, etc. Sort of what we originally planned footIcons for. I also need to just remove the footIcons code.

Alright, let me take a stab at that..

Yeah it should just be a tag set via addAttribute. I only ask that it renders as the first attribute.