In T7930#215278, @isfs wrote:

Something that would be useful to us would be the ability to create, or probably better, assign a task, as it nears a due date. E.g. we may set up a task due in a year's time, and anticipate working on it two months before it is due. It would be great to be able to schedule the task to be assigned on a particular date, and perhaps moved on a workboard. I don't think this would need to be any more complicated than a Herald action that runs at a particular date/time rather than in response to some other action. I'm not familiar with what Calendar can already do, as we don't have prototype applications turned on for our install, so apologies if this is already possible. I just thought I would mention this use case here for future reference.

The recurring and due date use cases in the previous comment would also be useful to us. I would prefer something more natural for the formulation, though, e.g. for tasks:

• when [Father Time] [reaches] value in [Due Date] (or other selected field), [Assign to] [ben].
• when [Father Time] [is one week before] value in [Due Date] AND [Status] is [any open status], [Set priority] to [High].
• when [Father Time] is [one month after] value in [Creation Date] AND [Status] is [any open status], [Send email notification] to [manager].

It would be great if task Due Dates (or other date fields, conceivably creation date could also be useful) could (optionally) appear on a calendar.

I'm having a tough time picking pieces apart here so that the transition is gradual -- many of the remaining behaviors are highly connected to one another and hard to tease apart. Things feel fine up to D17846, but even D17859 breaks enough stuff that I don't feel great about it, and doesn't seem to have pushed me through things enough to emerge on the other side.

arc linters phpcs shows both standard and phpcs.standard configuration options. Have you tried both?

• If you want to implement backslashes or thunderclouds as escape characters, feel free to do so locally. I don't plan to bring these changes upstream.
• If you want to strip zero-width spaces or escape literals, feel free to do so locally. I don't plan to bring these changes upstream.
• I do not plan to implement any sort of generalized inline escape character, sequence, or block in upstream Remarkup at this time.

Yes, it would be very easy! Feel free to implement such a rule locally.

Would it be possible for reMarkup to strip all zero-width non-breaking
spaces from its output, unless there was more than one in a row (in which
case the number would be decreased by 1)? That would solve the problem.

Heh, zero-width spaces are an option, yes. A bit too subtle in my eyes, but fair enough.

Okay: H3

I didn't mention backslashes on purpose, as I'm not specifically interested in any kind of escape characters. I just would like to have a specific occurrence of H3 to not be hyperlinked: any mechanism to do so would be fine, be it an escape character, an escape sequence, an inline version of the literal block, or something else entirely like an emoji. :) Thanks!

You can't explicitly subscribe to a revision you're a reviewer for because being a reviewer makes you an automatic subscriber (and, due to a similar bug to the one here, probably can't subscribe even if you've resigned, today), so you'd need to resign, then explicitly subscribe. Also, I'm not sure we handle the other way (explicitly unsubscribe, then later become a reviewer) correctly. These are tractable.

Perfectly clear.

@epriestley, @chad, is the use-case in T5301#218589 clear enough?

Adding a input box to the top so wherever you are you can just type in the task number you want to switch to, would be a plus.

Staring a bit more at the data I just posted, it occurs to me that it seems kind of sluggish for an UPDATE like those -- one row, indexed by what I assume is the PRIMARY KEY -- to take 1-4ms or so, as these are. There's probably a DB (or network-to-DB?) performance issue there that we'd benefit broadly from addressing.

We're still seeing this issue pretty severely, on our shiny upgraded 2017 Week 17 version on our shiny new Phabricator host. So I took a look just now with DarkConsole.

This issue is in fact actually fixed 🎊 ! Most recently, moving to a new host with a newer PHP (and everything else, running Ubuntu 16.04 rather than 12.04) made a big difference; we've also made a lot of improvements to our Phabricator setup over the past year or so, some of which likely helped too.

In T12689#223076, @epriestley wrote:

(But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

• There's probably one fairly narrow bug bug here: DifferentialTransactionEditor->getMailTo() likely includes resigned users but should not.
• Beyond that, when you've resigned, we should probably exclude you from getting indirect mail via a project/package? Maybe? (But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

rPbcd87e0e3f3756970d26d5e9c4a60e4be73ef6a6
rARC3c4735795a2963c5ddff6dceaf60122d01ca3dc0
rPHUa900d7b63e954e221efe140f0f33d3d701524aae

Need version information, please.

time well spent!

(It looks like I wrote this string myself, in D7159.)

Oh, the error just wasn't clear to me. I thought it meant "You must upload audio." in the sense of "you did not upload anything, but needed to". It actually means "You uploaded a file, but the file isn't a valid audio file as far as Phabricator is concerned.".

I'll poke at it.

Yeah I tried wav and mp3, safari and chrome, can't get an error here.

Here's what I'm seeing locally in Safari:

I can't reproduce "Attaching audio to a macro does not appear to work at all: always "You must upload audio.""... any ideas ?

Thanks, let me check that task and I tell you.

phabricator trading cards ftw.

Just noting that this cat is perfect and DOES NOT need any design improvement:

We might eventually support a trade/resale market -- one advantage is that we could give contributors something with slightly more valuable than stickers/flair/badges, but less complicated for us than doing fulfillment on schwag or dealing with taxes for actual money.

This might be a variant of T2465. There's some workaround described there that might help.

I was fully expecting a black market for mana points to be available.

I think that @epriestley just made capitalism and socialism obsolete by re-imagining everything in terms of Mana points. You sir, have won the internet.

• Windows version is Windows 7 with latest updates,
• PHP version 5.6.13,
• svn, version 1.9.4 (r1740329), compiled Apr 24 2016, 15:40:35 on x86-microsoft-windows
• arcanist version mentioned above

This should clearly be priority: Unbreak now!

This is a little light on reproduction steps. Can you give us more information such as the version information on Windows, SVN, local arcanist, if you attempted reproduction against a clean Phacility instance or against SVNTest here?

There were no commits between friday and today, so I'm not following what you're trying to tell us.

Everyone loves Opportunities For Improvement!

This stuff is probably going to churn for a bit but I'm pretty sure I'll forget about that thing if I don't write it down somewhere.

In View Options → Collapse File, we get into this sort of oldschool state:

Just merging this over to Facts, I don't anticipate allocating any resources to Maniphest reports before Facts ships.

T10469 is vaguely related.