See T13357 for followup.

There's currently a bug (likely related to D20652 or D20654?) where normal edits aren't respecting card order correctly during the redraw. I suspect this is just an order parameter getting lost somewhere.

a logical clock to complement the wall-time clocks

From D20653:

Just thinking out loud:

Here's roughly where I'm headed next. I'm planning to:

The "default" controller currently needs to "force" the URI parameters...
The "filter" controller currently needs to "force" the URI parameters...
The "apply" flow, where a new custom filter is applied...

A couple of weird cases on state management:

This is well-suited to a third-party extension, particularly after T5055.

See followup in T13105.

I'm going to call this effectively resolved:

In T5698#223992, @chad wrote:

Oh hai Cura uses Phabricator? I have a Lulzbot at home!

Oh hai Cura uses Phabricator? I have a Lulzbot at home!

@Krinkle, @pablocarrillo I second your requests. Great suggestion. I have a large README.md that I would love to split into multiple documentation files, without losing all the formatting.

Recent security issues in GitHub, GitLab, etc., with markdown:

I'm going to probably re-design this page a little.

The most important aspect in flexibility is the ability to support all locales. MediaWiki uses a system largely based on PHP's date() for historical reasons, see Language::sprintfDate().

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.

See also T10208

We take design feedback during product launches, and no other time.

@chad Ah bummer. Is there an official channel you guys recommend for feedback of this type?

Sorry, we don't take UI suggestions as feature request tasks, but do value the input and will keep it in mind.

I've marked D16806 as resolving this. Once that lands, here's the state of the world in terms of how the product works:

@rrfeng: You already brought this up in T11680 - please see and follow the reply you received there. No need to add comments in numerous places to decentralize any conversations about the (currently unclear) underlying issue you're perceiving. Please stick to T11680 - thanks!

I think the "graph trace" UI is not suitable for task graph.
The most scene which has problem is 1 task has too many sub tasks. And then the graph-status takes too much spaces of the page(It is so wide).

Oh! var_dump(...) or print_r(...) should send stuff to a big pink header on the page.

print_r($variable);
look at web page.

@epriestley PHP noob question: what do you do for debugging? I'm having a hard time just looking at the values of the variables involved here:

$pins = $request->getStrList('pin');
$pin = head($pins);
$app = id(new PhabricatorApplicationQuery())
  ->setViewer($viewer)
  ->withPHIDs(array($phid))
  ->executeOne();
if ($app) {
  $pin = get_class($app);
}

Ah, right -- I think those are both expected and that you're on the right track. You should be able to use $request->getStrList(...) instead of $request->getStr(...) to read the list, then head() to grab the first (item if it exists).

Alright I'm making a bit of progress here. Posting this update on the chance that there's something obvious I'm missing. The AphrontFormTokenizerControl behaves a little bit differently than the AphrontFormSelectControl. Specifically, this is what the form post data looks like the old way (SelectControl):

You can find this UI in Config → Home Page → Pin Application. Here's the relevant control:

@epriestley Is there a pathway for reading (not writing) edges which would be open to community contribution? Having arc patch Tnnnn functionality, pulling all the revisions attached to a particular task, would be really attractive for us as we tend to have a larger number of revisions per task.

This is working as intended.

Project menu?