There is no secret tracker with a different set of priorities or timelines
for features. Everything we plan is 100% open. This feature is not on any
short or medium term roadmap and you can read Planning for more
information on how we build the roadmap. We do plan to offer paid support
soon which will let installs prioritize features they need.

Hi,
My small team & I have been using Phabricator for a year. This is the feature that we lack and that makes our day-to-day work difficult. It would be nice to have even the basics (drag & drop to a column -> update to a given status). Any advise or workaround in the meanwhile would also be nice if they are some. Sorry if I lack Phabricator knowledge and missed an obvious workaround feature.

Milestones works great for this, but you still have to manually create the workboard (just going into workboard and clicking create - milestones show up).

We do something similar ourselves for technical interviews, but I just related all the tasks by embedding them in the description of a central task:

I think this use case is a reasonable one.

Yeah -- the workflow from the Maniphest side dumps all the values into inputs in the body and does a POST, I believe.

Interestingly I worked around the issue by doing the batch edit from the Maniphest search UI which is passing the selected tasks an HTTP body instead of a URL query I guess?

@swisspol hit a variant of this with 1,172 tasks bumping up against an Apache URL limit in the Phacility cluster when editing from a workboard column.

Based on two points of anecdata so far, things indeed seem snappier with D17959.

I have found that I can rearrange all the columns in some projects but cannot do the same in another one. Here's a screenshot. Now, I am not sure if it is a bug or just a random error.

For example, here is a project with more than 5 columns:

Please read and follow Contributing Bug Reports if you feel you've found a bug in Phabricator.

The rearrange dialogue box only shows a maximum of 5 columns although the project has more columns. This limits the ability of rearranging any column present beyond column number 5.

I think I shipped this.

That'll be 6 beers pls.

Super! We'll report results when we've got it deployed.

I shored up D17959 a bit, landed it, and deployed it to secure.phabricator.com, then spent some time fiddling with workboards here, but couldn't find any issues with it. We have ~6,500 "wishlist" tasks on this server and it distributed all tasks near 0 (approximately 2,700 tasks) evenly across the range [4096, 4096] fast enough that I didn't notice it. I'm currently inclined not to write a dedicated migration since it seems plausible that all existing installs will survive the first dispersal without much fanfare.

• I believe D17959 should resolve this.
• The new algorithm tends overall toward dispersing tasks over time, and clusters with more tasks should tend to cover an larger range, roughly linearly.
• The first few drags after the new algorithm is available may be very slow, since they'll spread the existing clusters out. After each large cluster has dispersed, all future non-pathological operations should be fast. (One pathological operation is to insert a million tasks at the same priority without performing any dragging, then perform a drag.) It's possible that cluster dispersal is fast enough that this isn't a big deal, although I may also just write a migration to normalize task subpriorities for everyone in advance of the new stuff landing so we pay this cost upfront rather than on-first-interacion.
• master has a bunch of churn already, it's late in the week, and this change is moderately risky (it's hard to undo damage if I got something wrong), so I don't expect it to make it into this week's stable release.

I'm not 100% sure, but from reading the subpriority movement code, it seems like our bell-curve distribution is self-perpetuating--when a block of tasks are moved, most of the time the next task is still relatively close, so $delta is small. I think this might be resolved by a big one-time readjustment to distribute tasks evenly throughout the space. I don't have an intuition on whether this distribution will redevelop over time, or if it's an artifact from the time before D12166.

This and T8588 have been a multi-year fishing expedition which I'm far from thrilled about, but I'll deal with this. 🐳

It looks like even after D12166, the subpriority-assignment logic doesn't do a great job of spreading our subpriorities. P2053 shows that very many of our tasks have subpriorities near 0 (in fact, the vast majority of our tasks; a separate query without the > 1 limit indicates that only about 4k tasks have subpriority neighborhoods of their very own.)

Staring a bit more at the data I just posted, it occurs to me that it seems kind of sluggish for an UPDATE like those -- one row, indexed by what I assume is the PRIMARY KEY -- to take 1-4ms or so, as these are. There's probably a DB (or network-to-DB?) performance issue there that we'd benefit broadly from addressing.

We're still seeing this issue pretty severely, on our shiny upgraded 2017 Week 17 version on our shiny new Phabricator host. So I took a look just now with DarkConsole.

or vue

good time to learn react

It's a day of re-thinking the entire UI for me. I don't want to shoe-horn stuff in.

From blame, it looks like D15278 originally stuffed these and some other things into a bit of a weird place -- I think we had some other problems with too much stuff in dropdowns at the time, and that was sort of a "shove this stuff under a rug for now" change? But I don't really remember.

T.T

Too slow @epriestley

Yes, see maniphest.points in Config.

Was this feature ever delivered? Just looking to hop on the right thread in regards to setting up variable task point values

In T12593#220668, @epriestley wrote:

I'm going to merge this into T12374.

If you have time, answering the questions in T12374#214870 on that task might be helpful. There are many possible implementations of this feature (e.g., per user/per workboard/global) and it's not clear to me which are desired from the use cases. It would also be helpful to understand what the major stumbling blocks are for using "bookmarks" and "saving queries to the menu" as workarounds (just cumbersome? Not the right scope/audience?).

Would be happy to see this feature. My company use different team names as columns of the work board. When a task is reassigned from a dev to a tester, I need to manually move it from Dev column to QA column.
With this feature implemented, I would be able to configure a rule that when a task is assigned to a specific person, the task will be automatically moved to a column, say the Dev column for example.

Currently the workboard has an option for fullscreen display. However this setting is lost when the browser refreshes. Since we're using Chrome + a Chrome autorefresh extension (SuperAutoRefresh) to display a Phabricator workboard on a bigscreen TV it would be useful if this setting is persisted across refreshes. Like ?fullscreen=yes as suggested.

I don't mean the project menu, I mean replacing the query menu on the work board with a confuigurable one like the favorites menu. I'd restrict it to task queires

I am currently using bookmarks to workaround the issue. I never considered using the project menu for the workboard views. This would certainly suffice, but it doesn't feel like the right place for it.

I think we have a basic query menu we could switch over to MenuItem, let users customize them per workboard like they can per project.

Two workarounds you could use here are:

Go for it.

@epriestley any objection to removing the "disabled" look here for workboards and subprojects? It's not a consistent pattern with "no permission" we usually use.

In T12330#213674, @chad wrote:

Do you think it makes sense to grey out "Subprojects" at all or have a tab for it when there are no subprojects?

Do you think it makes sense to grey out "Subprojects" at all or have a tab for it when there are no subprojects?

The funny thing is that event if I remove the file from Files, the coverage image in the Maniphest is still there. :)

+1 to hide cover as an option on the board

This would be helpful; post-T4900: Workboards updating in real time this would let the workboard be a broadcast mechanism of progress on an office screen, for instance.

Thanks for testing @jcox!

verified

T12214 was the task.

I presume this was fixed on Monday with b33bb3714bdb, can you verify?

I've seen the same issue (on latest stable install).

Just to clarify, I tested it locally, not on this install.

Request reopen, based on my above comment.

This does not contradict T5474, but compliments it. Both tickets are required to provide seamless operation

I think we can just offer more options in ProjectMenuItem

We could do some URL magic in JS to add ?fullscreen=yes to the URL bar when you activate the fullscreen mode, then respect that. However it will take 75 hours.

Move all cards in this column to <another column>

That would be very useful for us as well.

I'm going to merge this into T12074. Summarizing things so far and my short-term plans:

For T5214 / T12074, I am moving forward with an API query model where columns are associated with another, different object as a boardPHID (currently, always a project), and boards do not have their own objects or PHIDs.