Not a concern but a question: @aklapper why blanking Phortune-related SQL files on \phorge\resources\sql\autopatches instead of completely deleting them?

It returned to function again. Not sure why it wasn't working but good to see it working again.

In T15979#20270, @avivey wrote:

@Cigaryno which browser/OS are you using?

(I cannot reproduce anymore, now I see the very - ugly - native desktop notification of my environment lol; but it's difficult to note since I've configured my computer to disappear after 0.5 seconds - also maybe a common problem I guess)

The "Grant permission" button works for me on Chrome/Windows.

You are totally right, I've never seen native browser notifications too. For some reasons I've always confused Phorge's popup with these since they are quite similar in my environment

In T15979#20265, @valerio.bozzolan wrote:

Is there a possibility that you have a browser extension privacy-focused that automatically denies this permission?

Is there a possibility that you have a browser extension privacy-focused that automatically denies this permission?

Any error in your browser console?

Clicking on Send Test Notification, a notification shows up on the bottom of the screen, but this is totally unrelated to browser notifications.
After clicking on the Grant Permission button:

Can you share a screenshot after you click on that button?

In T15640#19898, @valerio.bozzolan wrote:

Wow. Assuming the line is the one with phutil_nonempty_string($branch), why branch "main" is considered a number?

I think that for the "the name I use is not my legal name" use-case, I'm pretty sure it's fine to use the name that is actually used (because that's what the person is normally known as). It's probably easier to justify accepting a name that is used in real life then "internet handle", but ㄟ( ▔, ▔ )ㄏ

Perhaps we need an interact policy for events?

What do other CLAs do about this?

I'm... honestly not sure, I haven't signed one before. If I had to, I'd ask the maintainers before doing so ^^;

Another related bug is that also referenced/attached files are kept on the old page. Maybe different bug report under same umbrella.

Let's promote to bug :D

The current workaround I'm proposing is just:

In T15121#20192, @BlankEclair wrote:

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

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