(That explanation might make approximately zero sense, I am not having a high-brain day today.)

This is probably the "object policy evaluated in the context of a different object" issue we've seen occasionally. If so, setting the visibility policy to any non-object-policy value (e.g., "All Users", or a specific list of users, etc -- anything which does not depend on the revision) should fix the error.

If we did add configuration, I think there are three ways we could do it:

A couple of general notes/thoughts:

Nice catch, thanks! D15619 should fix the docs.

• I'd currently consider this a user-expectation issue, but we're doing ourselves zero favors by not providing any kinds of hints about what expectation you should have. We should fix this first. I've realigned this task to discuss making the expectations/behavior more clear.
  • I believe the "edit permission is necessary" part of this rule is hard to reasonably get away from in light of column triggers (T5474). Not impossible, but hard.
  • The "edit permission is sufficient" part of this rule is easy to get away from, but we don't actually have use cases for requiring an additional project permission component right now (T6502).

My current expectation is that the rule is supposed to be that edit permission on the task is both necessary and sufficient to move it on the workboard, but this is almost certainly not fully reflected in the UI, and possibly not fully reflected in permission checks in some cases (?) although it sounds like we're good from this discussion.

The new *.edit endpoints can both create and edit, so a badges.create method would be redundant.

@psawant, thanks for the report and for your help building a reproduction case for us on a Phacility instance. It was extremely helpful in identifying and resolving the root cause of this issue.

A workaround is to give the repository a callsign Edit Repository → Edit Basic Information → Callsign.

This is a bug; see T10721 for followup and discussion.

Thanks, looking at this now.

I have taken down the public repository for time being.

This report does not describe a bug.

The staging area is a Git remote that we'll push to, so it should be a valid target for git push <url> ....

This is intentional, so you can use a task as a template to create other tasks if you have, say, several different "open" statuses. The "Create Subtask" action specifically forces the status to the default open status, but I think the current behavior is correct for bare ?template= which has been entered manually.

@paladox, you've been warned repeatedly about your consistently low-quality interactions with this upstream.

You did not test the patch. As I noted, the patch runs git fetch --queit instead of git fetch --quiet.

@paladox, your interactions with this upstream have consistently wasted our time and energy.

These things seem very general. I would expect them to be, e.g., on a wiki page like "Guidelines for Effective Code Review at <My Organization>". What advantage are you expecting to gain by building these into Differential as a checklist?

Can you give us some examples of the kinds of things you're checking for? Specifically, things where rote human review is the best solution to implementing a check?

This is the only difficult blocker for T7673, a bad behavior which is annoying and sort of user-hostile, so I'd like to at least plan our way through it.

I am going to merge this into T7303, which is a slightly narrower task describing OAuth access to Conduit.

The workflow to set a password on an account which does not have one is:

I think there's nothing actionable remaining here. Both our and Facebook's modern instructions encourage users to whitelist redirect URIs.

This report doesn't have enough information for us to move forward or resolve it. See Providing Reproduction Steps for help with writing complete, self-contained reproduction steps that we can follow to reproduce an issue.

On my mobile device (an iPhone 4S), I think it's slightly faster to tap-wait-tap-copy the URL bar than press-hold-copy a link.

This report doesn't describe a bug.

This should now be resolved in production.

We have an additional safety check which is supposed to prevent this kind of issue: we refuse to process messages with the same "Message-ID" more than once.

@paladox, we appreciate your enthusiasm but I think you have a very mistaken set of expectations about the kinds of services we provide. See some discussion in Support Resources.

We don't plan to support this in the upstream. We have a system in a similar role already (Harbormaster) and would prefer to expand it to do more if there is missing functionality.

I think this is happening:

Thanks for the report, D15573 should fix this. Sorry about that!

See Support Resources.

No, badges themselves don't have an awarder.

I know you guys want reproduction steps

jx-tooltip is a free spirit :3

This should now be resolved in HEAD of master. I've deployed the change here, and verified I can interact with the comment in D15565.

I think a workaround is to swap the particular changeset into unified mode (View Options → View Unified) and then interact with the comment, but the fix seems trivial and straightforward.

Thanks, I can reproduce this as well (e.g. D15565).

Too many deck slots, product literally unplayable.

FUN POLICE HERE

This is fairly messy and probably not worth fixing until the surrounding code is more modernized.

T7805 was the "use applicationsearch in the dialog" task.

I think this default ("all my open stuff") is probably the right one for "Edit Dependencies" and "Edit Maniphest Tasks" from Differential, and for "Edit Blocking Tasks", "Edit Pholio Mocks" and "Edit Differential Revisions" in Maniphest, although the argument for some of those is a little weaker.

In my flow I essentially only ever merge by copying the task ID, so the filter doesn't matter at all. Do you tend to search for the task by name?

Ah, interesting. I wasn't aware it was gone in PHP7. Given that, I agree that this probably isn't worth supporting (I've never seen this syntax in the wild myself).