Presuming this was resolved by D16095 since we haven't seen further reports, or new reports of brokenness.

We do not have Spanish. Sorry.

Yay! Thank you.

hi... good morning

As was mentioned, there was code already for detecting a hidden hash/anchor and loading older transactions/comments to allow it to be reached. Turned out it was a cinch to hook it up, which I've done in D16256.

This is purely hypothetical and it's hard for me to imagine users getting it wrong by accident.

After D16226, panels no longer support tagging.

This is working as intended.

We might have had some kind of dialog action from lightboxes in the past (or planned to have one -- like image inline comments?), but didn't have a lightbox action from dialogs until inline previews.

This was fixed by D16238 (Tuesday, July 5). It's available at HEAD of master and will promote to stable and be available in the Phacility cluster in a little more than 24 hours.

This is enormously complex to implement in the general case.

A possible fix to this is to handle ` on keydown instead of keypress (as we do for some other other keystrokes) but since we can't reproduce it we can't test that.

Your database may not have proper column encodings configured. Run this command to verify them:

D16253 should fix this; a quasi-workaround in the meantime is to set "Short Names" on repositories.

Thanks for the quick replies and actions, this is greatly appreciated.

I can't think of any reason it would ask that unless something changed locally. If you have no local changes to phabricator/, just reset to HEAD.

@chad I don't know, I installed phabricator under the direction of doc and then resolved some setup Issues.

Well, it turns out I mis-typed the project name! It's just the error message not so friendly. I can reproduce the error with this:

./move_beneath.php --parent aaa --child bbb --keep-members both --subproject

OK, I got it worked for 2 other projects. So there must be something special with the 2 projects I tried previously.

Good to hear!

ok, thx for infos. this sounds very good and I think, this request can closed :) at the moment the herald solution is working as expected

Thanks, I will try to test more.

Long term Nuance is our "help desk" tool, which is where we're be investing our resources. That will allow people to email support@ and have it queue into Phabricator for a response (which will work like Herald). You can have two way conversations in Phabricator without them needing a Phabricator account.

You should be able to do this already today with Herald and a custom email in Maniphest.

thanks, I didn't recognized this feature.

I can't reproduce any errors with the script against a new/clean install. Any ideas on what I can do differently to reproduce this?

Yes, It was some local encoding handling related and should not be related to the error. My code base is this:

I would like to auto assign all incoming support emails to my account. So I created a sieve-script for the shown example:

(Or likewise with the task ID.)

Is the commit ID exactly the same each time, or does it change?

Here's approximately where I'm headed with this:

Correction, not hanging, but continuously re-scheduling that task in the queue (which is slowing up the queue significantly)

I think we broke plain-text emails here:

Follow up question, this task has failed 38022 times.. is there some way I can punt it from our queue?

No problem, thanks for the followup!

@epriestley - this is caused by a downstream patch which intentionally excludes sprints from the displayed groups.

Per T1460:

Strange lines.

MotD

thank you for your compliance

I just added a new macro to our instance though

Oh, no, it's 268 and 286. No guac!

Wow, exactly 1,000 apart.

T10268 is also vaguely related.

Presuming this is resolved now, let us know if you're still seeing issues.

My tentative plan for this is a separate view where all inlines are shown in threads, sorted by done-ness and activity.

I'm not particularly sold on putting context in the timeline, particularly because I think we've received about as much feedback about Differential having "too much stuff" as we have about this context being desirable.

I'm going to close this in favor of more specific followup subtasks:

I don't plan to pursue this outside of the context of T1460, T8250, etc. If we did, it would be in the far future and after those changes land.

Upshot: I think renderValue($string) on ModularTransactionType is totally reasonable. We can fiddle with how it looks later.

I intend to remove them from feed, but it might have just been on a diff somewhere and not made it to a task.

I can't find the task. I'm like 98% sure @epriestley made one because someone kept spamming it on us.