Since this is at least a little bit of actual work, I'm just going to punt until we see an actual user request.

In T12949, we have issues with menu items sort of not having a sufficiently strong sense of identity and individuality.

Just musing to myself:

See also https://phabricator.wikimedia.org/T113556 downstream.

The task.open-count.status counts open tasks that are the result of a status change (an existing task being closed, or a closed task being reopened). Since it's much more common for existing open tasks to be closed than for existing closed tasks to be reopened, the series should go negative pretty quickly and stay there over time, more or less ending up with a big negative number of "number of tasks ever closed".

Not sure if it's expected in the current state, but here's one that doesn't seem well-formed: https://secure.phabricator.com/fact/chart/?y1=tasks.open-count.status

Just to briefly touch this:

See PHI385. I think I stabilized the dashboard arrangement issues in D19123, but the arrange workflows are still in somewhat rough shape.

One overarching issue here is that facts don't have a clear permissions model. It's bad if anyone can go look up the burndown chart for #critical-security-issues and then correlate that chart against tasks showing up in #weird-things-that-happen-when-you-hold-down-the-letter-a or whatever and get a hint about a security concern. In the general case, charts like "Salary by Employee", "Acuisitions Affecting our Stock Price", etc., are also potentially problematic.

• Fact cursors are currently per-object. I think they should likely be per <object, engine> pair so that subsets can be rebuilt more quickly for testing/development and the failure of one engine will not stop all other engines from processing data. On the other hand, fact processing is currently pretty fast and I don't expect to write a ton of engines so I'm not sure how critical this really is. Engines likely don't care how cursors work unless they depend on facts extracted by other engines and need to guarantee they execute later.
• FactEngine->getFactSpecs() isn't really authoritative -- it takes a fact definition externally. I think this should become the authoritative generator. That is, this piece of code needs to go sooner rather than later:

Somewhat related, if you have a disabled "Home" as your top item, we still show that regardless of the active dashboard below it.

T12956 has another situation where letting MenuItem generate 2+ items may be bad: we want to let a menu item steal the selection, but it's muddy to implement if each MenuItem can return several actual views.

For private reasons affecting the reporting install, this no longer has customer impact.

I think I didn't migrate this since there was no direct analog -- my memory's a little fuzzy, but I think the old query had some bugs / weird behaviors / general differences and there's no exact way to represent it after the change (and even if there was, the newer version -- with bucketing -- is probably way better for most users, so it's good to upgrade anyway). I figured it was better to just break it in an obvious way than subtly change it, which could be more confusing, I think.

T12708 is the same root bug. This was more engineering than I could handle.

I'm just going to merge this into T8033 since I our intent there is to prevent this situation entirely.

Yeah I can't seem to fix this ad hoc. My guess is it's never worked to allow you to skip the first tab. If I fix the error states, it then breaks existing tab panels. So we'd need to build a migration.

I just plan to fix the bug. That's the hard part of a 2-person team with thousands of open issues. Pick and choose the battles.

Thinking about this again, what about making this hard-coded numbered list instead a list of draggable items like it's used in Menu Configuration?

Based on like 10 seconds of looking at the code that's where I'd start. 💯

amazing what sleep will accomplish

I think i need to set the inputs with an actual key, not just [], so [$ii]

We should still be able to handle this case, but I can take a look at what's happening since this is a nonstandard element and the fix is probably easy once I understand what's going on with the logic.

@epriestley as far as I can tell, empty tokenizers do not POST an input to evaluate.

I can't think of any offhand. It might be easier to fix the dashboard/panel stuff first (i.e., inherit parent dashboard permissions) and then do this rather than the other way around, though.

@epriestley any reason to not implement Spaces on Dashboards?

I'm leaning here towards making empty buckets just disappear, and if all buckets are empty, No audits need your attention.