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 ㄟ( ▔, ▔ )ㄏ
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 17 2024
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 ^^;
Dec 16 2024
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:
Dec 15 2024
In T15121#20192, @BlankEclair wrote:Would the CLA have to be signed with one's legal name?
Dec 14 2024
Would the CLA have to be signed with one's legal name?
Dec 12 2024
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 :(
Dec 11 2024
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