EditEngine is a slightly different way to build forms that look the same as other forms, introduced circa January 2016. Some applications have moved to it, while others have not yet. It seems pretty reasonable and stable, though, so we're in the process of moving everything over.

First, let's sort of limit the direct damage this misconfiguration causes by changing this line in PhabricatorUserLog->initializeNewLog():

T7643#175911 has some discussion of this.

Is there a valid technical reason for Google to work like this?

Ah, nice! I'll write up some guidance on adding a setup check for this shortly.

In the read/write case, it's too late once we hit a hook -- we need to be able to decide which cluster node to send the traffic to, and we need to know if it's a read or write request before we make that decision, since there may be a nearby read-only node and a distant read/write node. If we can examine the stream and make a determination that the request is read-only, we can freely pick a nearby read-only node.

Today, we technically do not need to decode the protocol, but we will need to be able to distinguish between read and write requests to implement cluster read-only nodes (T10883) in the future and need to be able to rewrite the protocol to keep parity with fork-like/virtual-ref features that we plan to support in Git (T10691, T8092).

The action is indistinguishable from an update from Herald's perspective. Herald runs on the state of the object, not changes to it, so "Changed file content" will just match whatever the diff changes.

No one actually seems confused by Paste. Obviously documentation "should" exist, but probably not worth keeping this task around since it has just been idle for more than a year. I suspect we'll write it as soon as someone runs into a problem that needs to be documented.

We haven't seen more interest in this in a long time, and I don't currently plan to make compatibility-focused changes to the stack.

I'm going to merge this into T10448, which discusses limitations and improvements to the mail tags system. This is an example of a cross-cutting tag ("No Application/System Settings") that isn't handled gracefully by the current system, but correcting this and other similar issues is a goal of future work.

T7385 is probably also approximately this.

Commandeer fires Herald rules so stuff like "Require Legalpad Signature" or "Add Reviewers: that intern's wrangler" work.

The first page I found on the internet claims the iPhone 7 will be 1920x1080, so my strategy looks like it's paying off!

I think most of these are just moving into Application configuration over time, which tends to be a bit easier to use. I expect to just continue that trend in the future and this probably isn't worth building separately. I can't recall too much other confusion, and most of these are called <appname>.stuff anyway, which is fairly not-misleading.

This doesn't seem to be doing anything bad in practice. I think you can put the data in the URI if you want too and it works fine. Not clear that this is wrong/invalid enough to completely prevent it, and hasn't moved forward in a year and a half or so.

I think this was effectively resolved by D15775, which improved behavior for multiple cluster frontends.

T7074 may not be this, exactly, but they're close enough for government work.

This seems to be working, I think the last step is replacing the original call in the backup workflow.

We made this a little smarter and a little less prominent (on a non-default tab) and I feel like it's generally in a more reasonable place now. I don't currently expect to make it significantly more complex, and none of the rules proposed here feel like simple, unambiguous improvements to me.

We haven't seen other requests in this vein, exactly, in about two years, and we generally don't expect users to rewrite published commits as a routine workflow.

T6706 was the IP-address specific task.

We haven't seen other requests for this in nearly two years, and it can likely be implemented as an extension, except possibly for the weird cases mentioned above.

We haven't seen other users run into difficulty with this in the last couple of years, so I don't currently plan to change it.

This was filed a while ago, but it's not clear to me why this is useful -- no obvious reason to want to do this springs to mind.

No clue what this was, haven't had issues recently. I think config may have become simpler in the last couple years.

Although I don't think this is necessarily a bad idea, I haven't seen too much of a need for this. Some alternatives:

Ah, thanks! I think that should be relatively easy to fix.

We have an existing repository_badcommit table which is used to mark commits as "bad", where "bad" approximately means "the repository as a whole works, but the VCS tools can not read or should not read this particular commit for whatever reason". This is rare, but can happen when, e.g., third-party tools are used to write into repositories.

Have you tried following the instructions given in the error message?

Re-reading D9115, I think I was never able to understand or reproduce this and it was ultimately mooted anyway.

As far as I know, no users have actually gone berserk and deleted all their comments in nearly two years now, so I don't plan to specifically build comment removal rate limiting: this action does not seem particularly more dangerous or abuse-prone in practice than other actions like adding comments, merging tasks, etc. If a user did do this, recovery is likely not very difficult even without limiting.

I built a similar UI as part of D15926, but we declined to actually bring it upstream. It's possible that we may revisit this in the future, or that it may become possible via T418, but I don't currently plan to pursue this.

We now allow you control component order in the date control.

I haven't come up with any kind of rule for this in the last couple years which feels sufficiently un-magical, even in theory. It hasn't happened all that often recently, either, at least that I can recall.

This is like two years old now, and I'm pretty sure it works now since no one else has reported it and it would likely have come up when clustering was written a few months ago if it was still an issue. If anyone is still seeing issues, please feel free to file a new report with reproduction steps.

I think this was effectively resolved by D12773, since using conduit.token should evade the session timeout.

Sounds like we should write a "Screencastph" app!

rough life :(

This hasn't come up again in three years so I'm just going to assume that everyone is realistically installing 0.7.0 or newer nowadays. Today, optiping strongly recommends upgrading to 0.7.6 or newer to fix some security issues.

Let me see if I can reproduce this, but this is probably straightforward to fix -- I suspect some code just didn't get updated when Owners packages became mailable.

This a very old task that lacks root problem / use case information that we require for modern feature requests.

This general issue receives significant discussion in T3875. I don't think we've seen significant adoption of the unusual "stacked-on-the-same-branch" workflow, but similar concerns apply to branches-on-branches at the least.

I believe this was resolved by T6878 or related work. In the modern codebase, we fetch with --prune and explicit refspecs, which is sufficient according to git help fetch:

Ah, the project creation issue with gd issue is captured in T10405.

Also arc anist should probably be an alias for arc, so you can type arc anist diff.

Thanks! I still can't reproduce this. Here's the install I brought up, following your instructions as closely as possible:

This is not a bug report until it has reproduction instructions. If we don't get reproduction instructions, we will not send this to the bottom of the list -- instead, we will close the report as "Invalid" and ignore the problem: we can not move forward without reproduction instructions.

Strings with sentence fragments like that can be difficult to translate in the normal human language sense, see:

It's possible there's some weirdness, but I think it just works. Let me know if that doesn't hold up in practice.

This is probably something we'll need in the very long run for T6703 (if we legitimately let you connect to two different LDAP servers, it would be silly to have two "Login with LDAP" dialogs) but, yeah, using translation.override or just editing PhabricatorLDAPAuthProvider might be the shortest path today.

Per discussion T11508, I'm just going to officially call this a "feature".

(You are free to choose any other behavior -- even a useful one -- the requirement is only that arc weld do something.)

This will further familiarize you with arc. This may make sense to hold until some time after T5055, when arc workflows may change a bit. See also T11429.

You can find this UI in Config → Home Page → Pin Application. Here's the relevant control: