This is all frozen until we sort it out more generally.

is that expected for this?

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.

sorry that our DEEP NEURAL NETWORK TECHNOLOGY can not yet READ MINDS

(I think this only impacts Diffusion, not Differential.)

For completeness, the "20 other subscribers" dialog displays disabled users in a different, unique way that isn't like any of the other ways (grey, no dot, no strikethru):

I'm going to merge this into T12164, which I think is a more powerful approach on this.

In Paste (and I think Differential), we scroll lines instead of trying to wrap them:

This task does not capture abuse cases. If you'd like us to build anti-abuse tools, please file a separate request describing the abuse you're seeing. See also T10215.

Particularly, see T9430.

Is that feedback based on the Audit dashboard at HEAD of master?

From downstream, MariaDB has a fairly severe bug when indexing tokens with length greater than 127 bytes:

I have discovered that we already have PhabricatorDashboardProfileMenuItem.

Yeah, you should be good now. I'll look into the JS thing since we like money.

Oh! I thought that mock was a screenshot and that "Home" was a new DashboardMenuItem. No conflicts, I'll shoot you a diff in a bit.

Yeah, but since you already wrote DashboardMenuItem we'd conflict -- do you want to just diff that separately now, then I'll fancy-it-up and it should integrate cleanly?

We shouldn't need to build a route into the applications separately -- getProfileMenuRouting() already adds a route (from the code, I guess the actual route is /home/item/view/123/).

Yeah, fully agreed that we should stay in Home in terms of the nav menu, crumbs (none on Home, but relevant for Projects), checking application permissions, etc. I just got scared off by "AJAX", since I think the non-ajax thing will take me 20 minutes and an Ajax version would take me 20000 minutes.

If you just want to diff that when it's ready I can implement the fancier version to get the dashboard rendering on the same page. Looking at the code, it's not quite as simple as I remembered -- I thought we had some similar panels already, but all the stuff we have is more hard-coded than I thought.

I mean if you're on home, and you have 3 dashboards, that you don't leave home. I think we talked about this before and you said that was simple.

That is, the rule the menu already uses is already "show the item the user has explicitly selected as the default item, or the first item which they could select as a default, if they haven't selected one yet". This is what lets you pick projects to default to the workboard or project profile, but causes them to default to the project profile.

Selecting first dashboard as homepage. I think I can just query the menu itself in MainController and pull it out? Use built in home if nothing returned?

🐈

Downstream, @20after4 calls out that mentioning disabled users in comments still subscribes them, as though they were normal users. This behavior would be easy to change, but I could sort of go either way on it.

I think we have some discussion of this somewhere, although I don't immediately recall where and it's not in the obvious places. I might be conflating discussion of the recently-reworked "Available" status.

Ah, that's probably from an earlier git pull. Each of those merges have two parents, like this in the most recent output:

I'm not entirely sure what I did here to screw that up.

According to that test, your server does not support InnoDB fulltext, so what you're seeing is expected: we keep the tables with FULLTEXT indexes on MyISAM if innodb_ft_max_token_size is not a defined system variable.

It looks like my server supports InnoDB fulltext search

I don't think this is a stemming problem. Note that we MATCH(corpus, stemmedCorpus) against the query, so we're actually searching in the text "this is a test thi test". I wrote stemming so that it should never match fewer documents than an unstemmed query would -- definitely possible I got something wrong, but that's the intent, at least: stemming only gives you more hits.

I can get around this by just hashing some unique string that makes up the error and dumping that into the task description and search off of that since full-text searching for single strings works as expected.

What for is "audit.can-author-close-audit" then?

You could also add a condition like this to your rules which trigger audits:

he has to remove the group and add himself as Auditor

Can you describe how audit works in your organization and why you want authors to be able to close audits after T2393?

After D17252, audits now have a "Request Verification" action and a "Needs Verification" state. These states prompt auditors to verify the remedies the author has offered have addressed their concerns. Intended usage is along these lines:

I'm going to merge this into T2393, where I'll discuss this shortly.

I filed this task from the perspective of what it looks to the user, not from the engineering implementation perspective.

Does my email about refs/pull/68/head explain this behavior?

Is there some scenario which can trigger both bindings in a host group to be brought online?

What possible use case could anyone ever have for putting a THOUSAND lines of source code in a single file?!!

Without actually reproducing this or looking at the code, I believe this isn't a bug. You're expecting Drydock to choose particular allocation strategies:

No easy way to apply a policy to a group of repos.

He's so little. :)

Poor 🐈.

I guess I don't even have a glyph for :lion_face: anyway.

Also while you're in there maybe replace _ with (space) in the strings? I can't find :lion_face: by typing :fac... right now, but I think if you swap the underscores for spaces it will work. Then :cat should be able to find crying_cat_face and stuff, too.

not memorizing emoji collation order in 2017 pfft

The list is sorted by emoji. 🐈 is "alphabetically" earlier than 🐱 in the list of emoji.

D17242 should fix this, thanks for the report!