Yup, no one in general chat is disabled.

"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.

Maybe like, yellow or orange... indigo... vermillion?

At a minimum I'd prefer a different icon than administratively disabled. Mostly, I don't think it matters this information is conveyed, since it sounds like it's expected to be temporal?

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.

Like if we just send notifications if you're not verified, I think that's sufficient

Do they get notifications? Or we cut out completely? Basically I'd like to remove the dot for email-not-verified if possible.

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

Right.

Do we not send email to unverified people now?

(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?

Would also like to see "/here" in Conpherence send a notification to all users in the current room.

I have to type @epri and @amck to find you both, and it's my most common mention.

This should probably work globally on any object.

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:

Well, this is a GitHub-like isn't it? In the context of what was quoted, it was specifically GitHub itself that was mentioned.

I'd guess most people use the free Phacility plan because they need private repositories.

I don't think so because there are GitHub like solution that offer private repositories for free.

I'd personally be completely happy if all free users use GitHub forever and we only take their paying users

Actually, I figured it out... The problem was that I had security.require-https set to true but I hadn't yet setup HTTPS so I was only using plain old HTTP.

I tried to reproduce this on a Phacility host, but it doesn't reproduce there because the first user account is setup via OAuth.

I think we should remove the CAN_JOIN. If you can see it, you can join it. I don't see any parallel in Slack and looks like there are mods that add it forceably by kicking you off a channel if you leave a message. lulz.

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

(◍•ᴗ•◍)

\o/

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.

I can confirm that the solution works properly. Once again, thanks! :-)

Thanks for the suggestion. I'm trying that now.

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):

We routinely have multiple commits on multiple branches because we mirror (via Harbormaster) our master branch to an experimental/master branch. This is safe because the two branches are never touching the same paths.