I generally expect all signing to be external, at least for the foreseeable future.

In the case of Debian 9, it looks like it won't even freeze for 6 months. If it ships with PHP 7.1, it may well run Phabricator. It is impossible for us to answer compatibility questions about hypothetical software slated for release the better part of a year from now.

In this particular mock it's slightly confusing to me that the left nav looks like it has a "Table of Contents" header but is showing a document hierarchy (i.e., element that looks like a header does not seem to be labeling the content beneath it). Not sure if that's a mock thing / interaction thing / whatever.

It would also be nice to recognize that "oldname" became "newname" so we could redirect, continue delivering mail, etc. This is a little more involved.

Oh, I think I made up point (1) above -- that's already the behavior.

I'd like to make the Diffusion UI more field-focused (T9713). which is maybe adjacent, although not directly related.

Also, please note this:

Example 1: Batch edit of more projects at once - obviously easier to run script than having to click it manually.

Try now?

See also T11401, although this started life as a Pholio task and that's now a code-specific UI task so I don't know if they're actually the same.

Yeah, I think this is largely an issue of how much space we have in the UI.

I deployed this stuff here. I neglected to get a production timing beforehand so I can't really claim it's actually faster, but it seems fast-ish now. Let me know if things look better and/or I ruined everything when you get around to deploying it.

How about this: we'll play the "5 whys" game described in Describing Root Problems to get to bottom of this problem. After we figure it out, you tell me why you didn't provide that information in the first place and how to improve the documentation so that it's clear what we're after. Sound good?

I don't immediately have an attack on the JIRA thing (it should be less expensive in normal cases), and don't want to do the Auth stuff without more planning, and nothing else leaps out at me as having a similar sort of value for the cost.

There's still quite a bit of room here. Locally, I see a 220ms call for differential.revision.search. Here are savings which look fairly easy to capture:

That sort of leaves you in trouble with custom edge-based fields like the one above, but a reasonable short term approach is the one you've already taken:

Ah, there are really a couple of issues here.

Please please please please please please please please please please please please read Describing Root Problems carefully and think about what it is asking for.

That looks broadly correct to me, I just want to try to remove the assumption that the first object's first field's storage is universally the right storage in fixing this upstream. It's always true today and for the foreseeable future, just obviously not a Fundamental Axiom of the System. Let me review D16346 and I'll spend 10 minutes on this, I'm pretty sure it's straightforward, not a weird snowbally mess, and that the upstreamable patch is only cosmetically different from that one.

I think the issue is that there's no callable thing for bulk-loading custom fields right now, which is why SearchEngineExtension doesn't have a hook for it. Other SearchEngine extensions don't need it since none currently load any data.

T10635 is vaguely related, too.

See Planning for help understanding timelines and priorities.

I can't reproduce this here, locally, or in the Phacility cluster. Can you? You should be able to push to rGITTEST on this install, or launch a test instance from admin.phacility.com and create a repository there.

This is not an expected behavior.

I'm going to close this in favor of T10448, which discusses fixing "other" tags and generally improving how tags work.

I think custom forms (today), workboard support for custom forms (likely, in the future), and T8442 are the most promising ways forward here.

It's still not really clear to me what this issue is describing. Here are my best guesses at how to fix various things which might be problems?

T7961 is probably worth fixing while I'm in here.

I'm going to at least fix the instanceof mess before adding a Calendar adapter in T7939.

Calendar is currently prioritized, but the scope is focused on basic functionality (getting it out of the "prototype" stage, roughly described in T11326 with more recent activity in T11326) and API integrations (Google Calendar in T2334, ICS in T10747).

I'm just going to close this in favor of T10038. The short answer is: write bindings.

I expect to do this eventually, but I'm hesitant to just put a freeform "Location" text field on events. If we do, we can't prevent double-booking physical meeting rooms, since users may spell physical space names differently and we can't know for sure that "Meeting 6", "Meeting Room 6", "Meting Rum Six", and "Meeting Room#6" are all the same.

Thanks for the report, and for including detailed reproduction steps which allowed us to reproduce the issue.

See T5447 for information on reusing Phabricator code in third-party applications.

What version of Phabricator you're running? See Providing Version Information for help figuring it out.

I think this was obsoleted by T10003 and EditEngine.

This UI is on life support until Facts (T1562) gets built, and I don't plan to make any upstream changes/improvements.

I think this is possibly undesirable to resolve in the general case, e.g.:

Phabricator's infrastructure has evolved a lot and CustomFields now serve a smaller role than they once did -- roughly, just custom fields. Later generation stuff (particularly EditEngine) feels better factored, and has reduced the responsibility of CustomFields.

When we make a hire we can make them do this "to become more familiar with Phabricator's codebase".

I think we pretty much have clarity on stuff this task was tracking:

At HEAD of master, this is now supported. There's no default UI for it, but you can get to it in three ways:

Tentatively, I'm thinking about doing this (some discussion in T4788, too):

I think the commit stuff is working properly already -- the code is a little tangled, but we try to merge revisions into that section if we can, and only render it separately if we need to. That is, we attempt to render: