Would the CLA have to be signed with one's legal name?

Uh I'm very happy about this at work! Running since months smoothly. I can close Google Calendar forever 🎉

I see a red light in a unit test but it works on me after the patch src/parser/__tests__/ArcanistBundleTestCase.php - any comment on that? Anyway sgtm since it needs the foreach() stuff later.

It also works with icons that are spinning lol thanks

I wonder if we can expand that to provide an authorUser too, in many places as possible 🤔

but i'm lazyyyy :(

Thanks for the super-quick patch! I can confirm that this fixes the issue in the Phriction ToC on wider screens.

I've discovered a minor UX problem if an heading has a nice icon. Check it:

Thanks! That worked :)

Welcome in the family of Trusted Contributors \o/ try again plz

@aklapper I'd like, but don't have permissions to push to the repo:

>>>  Land these changes? [y/N/?] y
MERGING  c63c9545c8c1 Fix error in Mercurial when no offset is specified
MERGE  Attempting to rebase changes.
DONE  Merge succeeded.
PUSHING  Pushing changes to "origin".

In D25853#22877, @BlankEclair wrote:

$params has an optional authorPHID key, whose value is... well, the PHID of the author (if applicable). I suppose we can reuse that here?

@jeffrey: Would you like to arc land your patch to get it merged?

@bekay: Would you like to merge this?

Turns out that this doesn't work if the file is uploaded via chunking

$params has an optional authorPHID key, whose value is... well, the PHID of the author (if applicable). I suppose we can reuse that here?

Hoping to help: maybe maybe, we can be prepared to receive that User $actor but: null as default \o/ and we can just skip this additional limitation if it's null, assuming that null = SomebodyImportant™

Ouch we should maybe already skip this limit if the user has $user->isOmnipotent(), otherwise some daemons may crash.

Move assertion to a different function

Thanks folks 💃 Let's land and open visibility, so other people can read more and cherry-pick in their stable if they need.

I forgot to accept but please consider the little cute small comment to add the corner case for the background ajax request, that I suspect it may work too and I hope with less unexpected situations. There was probably a reason for that isFormPost(). For example see isContinueRequest() that is even stricter in a way. Thanks :)

I like it :) Thanks! It works on my machine following the test plan.

(we can probably keep this ticket open, so that we have the 2nd part on the backlog. I'm pretty sure we want it to happen "eventually".)

Feel free to show something early :) That would attract more attention than the Discussion Needed tag I bet

Wrote the code for the first phase :p

Sounds good to me :p

Thank you!

Let’s do it

And another typo

If there are no objections I would be happy to accept the diff. @speck are your concerns addressed or should we continue discussion / consider other options?

fixed capability

In T15965#20144, @valerio.bozzolan wrote:

What is changing is, that unverified email will not match your unverified email as default, so that should need these 2 clicks manual configs (or, find a way to verify the email)

Yep, manually setting your unverified (and not verifiable) email would still be possible 👍 just two clicks are needed from this kind of pages:

Another edge case: Most of my contributions to Phorge happened as part of my work for Wikimedia. Those commits are under an email address that I no longer have access to, since I am no longer employed at the Wikimedia Foundation.