Totally my fault, I just didn't read half that sentence. 🐈

And thanks for the report! Let us know if you run into anything else.

D17687 should dirty the cache properly on username changes. It should promote to stable within the next ~12 hours, and deploy to Phacility production about 24 hours from now.

I was able to resolve the issue by deleting my user's ssh key, and uploading the original ssh key material as a new Phabricator sshkey.

See also somewhat-related task T12397.

Maybe you will see a tree on vacation!

"RU SUB" DKP are the best DKP.

There are probably a couple of tags on hovercards and maybe user profiles which should be color-coordianted for consistency.

Orange and red/vermillion are already used for "Away" and "Busy", and I think green would be confusing (similar to "online"), so maybe indigo/pink/blue/violet?

"Busy" and "Away" are temporal too. I think all three states are important: they indicate that you shouldn't expect a response from the user.

If auth.require-email-verification is off, they receive notifications in Phabricator itself.
If auth.require-email-verification is on, they can not log in or see anything until they verify their email addresses.

(Although I think the dots appeared before that change, when you enabled auth.require-email-verification to combat printer faxers.)

Right.

(But almost no users in General Chat are actually disabled, I think -- all the dots are for unverified users. Not sure if those should act the same, since we probably wouldn't sort away/busy users to the bottom? Also, why not just kick those users out in normal cases?)

Maybe just sort them to the bottom?

In particular, when you connect over HTTP to a security.require-https install, we normally just immediately redirect you to https://....

Was this on a test install on localhost? I can only reproduce this if the remote address is part of cluster.addresses.

This could definitely be more clear, but I think this is currently expected -- you still need to have valid configuration even when providing additional administrative credentials.

(And I think "Conpherence as an announcement tool" is a very marginal use case anyway -- today, Phame is probably better already?)

That seems reasonable to me. We could implement a "read-only" equivalent later by having a flag like "require edit permission to send messages to this room" if we need it. That probably makes more sense anyway -- I can't really think of any use cases where a room is sort-of read-only, but the users who can post to it are different than users who can edit it.

To clarify, I meant this:

I'm only like 85% sure that D17667 really fixes things so yell if it still looks ~weird~.

Searching for ひらがな or 漢字汉字 or 漢字汉 now finds this task. Searching for 漢字 or 汉字 does not, but I think that's because they're under the minimum token length.

漢字汉

ひらがな
漢字汉字

漢字
汉字

Great! Handling of branches is definitely something we'd like to improve in the future, but most of the improvements we have planned require significant amounts of work. If you eventually run into limitations with this approach, hopefully we'll have some improvements in place by then.

Er, that wasn't even close -- this is simpler and actually works:

I think you could do something like this (made-up pseudocode because my bash is garbage):

• PhabricatorSyntaxHighlightingConfigOptions defines this option.
• Change the type from wild to custom:SomeClassName to switch to a custom type validator.
• The new validator class should subclass PhabricatorConfigJSONOptionType.
• You can look at PhabricatorKeyringConfigOptionType for a (more complex) example of how to validate a value.
• Test by trying to change the value to something invalid, you should get an error.
• You can test a regexp is valid like this:

Cool. We'll improve this in the future and make it easier to find once we do.

This is essentially complete except for the Google Cloud specific issue with MyISAM being unavailable; I'm going to retarget it for that.

("We don't want to do that just to make Phabricator work" is a completely reasonable response, but at least in this project this practice seems useful and we'd probably keep doing it even if branch information was more accessible.)