That seems to be doing something fairly reasonable in my client, yell if it looks funky somewhere else:

I think this isn't really too bad. The major issue is that we can't use stylesheets in email because Gmail doesn't support them, so we need to emit markup with inline style attributes.

This is now live in HEAD of master, and deployed to secure. Here's phabricator/ on this install:

I'm going to call this resolved now -- there are still substantial rough edges with this and the rest of T10748, but we're running on the new code and everything else should mostly be UI stuff. T10922 has general guidance and I'll open an errata task to track cleanup shortly.

D15837 appears to have deployed cleanly here.

And I think the mail notifications are also largely reasonable, I just don't want to hack this one mail notification in and call it a day since this I think this should be approached more broadly (covering all high-security actions, not just SSH) and deeply (SMS, mail, transactions).

My only idea would be converting actions surrounding SSH key management to transactions, which you're not explicitly stating here, but if we were to do that we would be able to use internal infa we have that reacts to transactions, and send email when a key is added.

Some things we can do easily here:

I suppose we can trust X-Forwarded-Proto for the purposes of raising a setup issue, although I'm not sure if that would help here, since I think the header usually won't be set if you use nginx to terminate SSL instead of, say, an ELB.

We're extremely unlikely to pursue any changes where 99% of the time it works great and 1% of the time a user shows up here wanting to kill us, so arguments in the vein of "it would work for me and other reasonable users who know what they're doing", while likely true, has very weak persuasive power.

You can see which fields are copied in Edit Task → Configure Form → Using HTTP Parameters and scrolling down to "Template Objects". On this install, these fields are currently copied:

I suspect you may not be setting $_SERVER['HTTPS'] so Phabricator believes you are connecting over HTTP. It looks for a client using the http protocol, fails to find one (only https is available), and does not emit a websocket setup instruction.

A branch or tag can be moved from a very old commit to a new commit, and then re-run rules on a large amount of repository history.

Broadly, there are a class of "security" changes which are really policy compliance changes. For example, it's common for large enterprises to have a password requirement like this:

In T6522#173738, @reardencode wrote:

for (commit in commits_between(ref.old_commit, ref.new_commit)) {

I've generally been hesitant about making Phabricator send these emails because I'm not sure how valuable they are in practice, and a lot of users hate email (see T9161). If an attacker gains access to an instance even briefly, I think it's likely much of the damage is done before most users will be able to respond (in particular, a targeted attack can virtually guarantee you receive the email at a time when you are likely to be asleep). By its nature, this mitigation is a reactive one with a potentially long reaction time.

Per F1256292, presuming resolved until more details surface about what's up.

...and the simple task count ones were just as good

Some teams are confident that they can evenly size tasks

You can set a global default in Edit Task → Configure Form → Edit Form Configuration → Change Default Values → Type Some Number → Save Defaults.

Cool. I'll merge this into T5000, then -- beyond the mechanics discussed there, that's broadly the "provide smoother onboarding workflows so you can use Phabricator more gradually" task.

You can click the buildable to get a positive summary (see B12021, e.g.):

See also T10691.

I can't reproduce this. Here's what I did. I created this Herald rule:

It's also fine to not fix this, or just fix some of it -- the affected tasks shouldn't do anything bad or break anything, even though their state isn't totally consistent. They won't respond correctly to queries (e.g., querying for tasks in the milestone won't return affected tasks, since they aren't "really" part of the milestone anymore) but should behave normally other than that. So it's not critical to hunt down every single affected task.

Thanks for the report! This is a definitely a bug, and should be fixed later today once D15834 is reviewed.

This is supported, just not by the plugin you're using (which we don't maintain). Here's an example:

I'm going to merge this into T10748: the modern diffusion.repository.edit endpoint it provides is the pathway forward here.

I'm going to merge this into T10748. It should technically be fixed by D15829 on its own, but will be fixed even harder once we cut over to the changes in T10748.

I'm going to merge this into T10748: this should be fixed by D15829, but won't go live until after we cut over to the new UI as part of the changes in T10748.

When Phabricator used this UI, we consistently got feedback from many, many new users that it was overwhelming. In particular, it presented ~30 applications while the modern default navigation presents about ~10.

Ah, sure, that makes sense.

This one is obviously ghosts. How could this possibly be anything but ghosts?

I think it's maybe in the PHUIStatusView here?

This is now mostly built as a new "shadow UI" and we're nearly ready to cut over and start having it affect repository behavior.

This substantially exists at HEAD, but Diffusion doesn't actually use it yet.

I'm going to merge this into T10748, which has implemented these endpoints, although they won't be fully functional until we cut over to the new URI code, likely in the next week.

I'm going to merge this into T10366. This will be supported once we cut over to the new code there, likely in the next week.

I'm going to merge this into T10366. The changes there support customizing which URIs are shown as clone URIs, adding arbitrary new URIs, and disabling or hiding the first-party URIs.