@20after4, D13252 changes the signature of two methods in PhabricatorPolicyRule:

It will be possible to define this rule locally after T5681, but I don't anticipate bringing it upstream.

Presuming this is resolved since we found a reasonable explanation for the case above. Let me know if anyone is still seeing issues.

Maybe -- it's linked for me, and I would expect it to be linked for you because you have access to the space:

This was fixed by rP9c82881c, which is slightly ahead of you.

We want this for T8488 and it's probably a component in moving T8434 forward.

Per T8498, you can now send mail to test-space-bugs@phabricator.com to create tasks directly in S2 (join Space Test Users first if you can't see it). T8514 is an example.

Ah, interesting. I'm glad to hear it's been working out (although I'm a little surprised!).

Yell if that doesn't actually fix things once it lands, but I'm pretty confident it's the issue.

I'm also not sure how well arc patch handoff has been working for you, but T8090 has some discussion of some more reliable approaches we're evaluating and moving toward.

This is an artifact of the PHP json_encode() method's rules for guessing whether a PHP array is an JSON object or a JSON list.

Development Log

Thanks! 99% sure that's the fix, then: you're on a 32-bit system and the 'int' type can't represent the 64-bit chronologicalKey.

It's possible that the paging code is breaking somehow, although I still haven't been able to reproduce this and can't see any way it could. Can you log the value of $cursor passed to getPagingValueMap() each time through the loop? It should look like this:

We aren't interested in making this a default.

Thanks! I think D13245 should really fix this.

Although T4207 is sort of related, in that it proposes a new kind of "parent/child" relationship (distinct from "blocks / blocked by").

Oh, sorry, I completely misread, ignore me.

See T4207 for task graphs.

There is no way to disable this.

You can likely work around it in the meantime by setting isEmailVerified to 1 in that table. (I expect D13239 will land in the next few hours.)

Sorry, bad at reading. Yeah, that's the issue. D13239 will fix things.

Oh, is auth.email-domains set?

I poked at this a bit, but it doesn't feel great to me, at least with the current header design:

D13239 will fix this in some cases.

Maybe. Do you have approval queues on, or email verification on?

I can't reproduce this locally.

(If you can, set debug.time-limit to 10 and then repro it; it should give you a more useful stack trace.)

Can you reproduce this by calling feed.query manually from the web UI?

No problem, let us know if you run into anything else.

You can use maniphest.statuses in Config to create, remove, or change statuses.

I'm also still not totally sure that we need/want icons. I'm probably going to do a diff where we just use the icon everywhere and see if that looks reasonable or not. If it's better than names, we can go from there.

Hmm.. I'm not sure if we'd pick up enough generic/flexible icons to justify adding it. A lot of the icons seem not-generic-enough or duplicated in Font Awesome.

After thinking about this, I sort of like reserving some of the more geometric shapes for Badges (T6526), since v1 is probably going to have to use icons.

I can't reproduce this. I created T8499 and immediately received mail about it to my "molepeople" list:

Development Log

This looks like it's done, although we may revisit it after T8434 has a more solid path forward.

If you want to pick some unobjectionable "default" token which is not a valid tag or branch name in Git or Mercurial (and, ideally, unlikely to ever be a valid ref in any VCS) I'm happy to implement that and shove it in the documentation. Not great, but seems least-bad to me.

I think the original form only worked by accident, we don't use it in the UI anywhere. This behavior likely changed when I fixed T7100.

I'm not sure how much I'd trust a !space command to be honest.

I think the difference with the Wikimedia Procurement use case is that tasks with files are created via email (i.e. a provider sends an offer to an email address).

At HEAD, the underlying use case discussed on that task should already be secure:

Here's how it works slightly-ahead-of-HEAD:

No, I'm not using auth.email-domains.