Defining permissions for newbies that may be distinct from the "got the hang of it" crowd

(You could put more ignore stuff in the route too if you want the blog title.)

You can probably just do that by adding a route like this:

Yes, but blogs don't have slugs right now and blog post slugs are editable.

The interaction between Maniphest "Can Edit X" fields and the new form stuff is also currently quite bad. I've restored 'Can Prioritize Tasks' to "All Users" on this install, since users otherwise can not create tasks with the new forms.

The story on SNI actually looks pretty reasonable (we're mostly just losing IE on XP and very old mobile devices), and should be more reasonable by the time we're thinking about whitelabeling main instances.

It's also possible that we can roll our own loadbalancers by assigning a lot of elastic IPs to a single host. This currently allows us to put ~240 domains on a host, at a cost of ~$4 per domain per month (for the elastic IP) instead of ~$20 per domain per month, but is more work. In contrast, SNI would let us put thousands of domains on a host with no cost per domain.

One other thing is that custom domains won't work on Phacility by default, and I don't think we can easily make them work (we can't just have users CNAME their DNS because we won't have the right SSL certificate). So maybe that's an argument for removing the feature or adding an option (ugh) to disable it.

I'm consistently not seeing a comment preview on T9910. Likely trace:

The major product issue I'm now unsure about is what form we should use when you interact with the create/edit flow from places other than Maniphest → Create Task. Exhaustively, I believe these are:

That makes sense, and should work well if you're able to convince developers to use arc feature (or the underlying branch flags, or I think branch.autosetupmerge in Git config?) consistently. You might also consider leaving git:branch-unique(...) in the ruleset after arc:upstream -- it should behave well in more situations than git:merge-base(...) will, I think, and it might be preferable if the penalty for not using --track is "things work, but are slow" instead of "things don't work".

Just to be clear, after this week - sites that upgrade but are tracking the stable branch will be affected by these changes?

Policy junk should be fixed.

The basics of the ApplicationEditor stuff are now live on this install, and T9908 has some discussion of the direction I think we can pursue for the "Security" use case.

Edit forms are causing some policy checks to apply incorrectly so tasks (which should be public) currently aren't. Looking into that...

One severe regression is that the description textarea in the create form is tiny now. I need to make that gigantic again.

I landed what I've got so far, pushed it here, configured it a bit, and described what I've done in T9908, for the curious.

Cool, let us know if you run into anything else.

(At the least, I can't reproduce these issues at HEAD.)

You're a few days out of date -- I believe both of these issues are fixed at HEAD. Can you upgrade and let me know if you're still seeing issues?

Specifically, you're talking about this?

will the patch be reviewed and merged

That's the workflow I use, but I --amend "feature" when updating it.

Task creation slightly ahead of HEAD through maniphest.edit now hit essentially the exact same code as the web UI, and no longer appear to do this "[Reopened]" stuff.

This hasn't hit HEAD yet, but will be resolved indirectly as part of changes in connection with T9132 shortly as that rolls out.

See T4103 (or create a wiki page or dashboard).

I'm removing this "Create Project" workflow entirely in connection with T9132, obsoleting this task.

This is now fairly easy to implement and the race stuff isn't a problem anymore, but I'm not sure it's worthwhile from a product perspective. We could pursue these things fairly easily now:

See T4200.

I think this is mostly either resolved or obsoleted by "Email Commands" (Help → Email Commands in Maniphest). We also backed away from hashtags implying project associations, and that seems like it was a good call.

We haven't seen other use cases for this. OAuth or Nuance are more likely approaches from an upstream viewpoint.

Actually, you probably also don't really care about removing the comment event anyway, since it can't change policies and you can't comment on objects when creating them, and I think your listener doesn't actually end up doing anything special for the actions that are available? So this might be mostly moot anyway, but in an ideal world I'll get through the main "edit" event shortly too.

Quick update here: ApplicationEditor/EditEngine have caught up with this, so the current plan is to indirectly remove this event in at least some cases (currently: changes made from the "Comments" area) after the stable cut on Saturday. You can upgrade to this week's stable safely but we should make sure things are in a good place before you move beyond that.

pretty big rough edges for the workflows it intends to enable

I think there are two issues here:

I think this is a problem only with the default font, it seems OK in other fonts:

I think the first SSH connection is still more expensive than several HTTP connections, and we can't easily just pool all traffic from a host over a single connection because a host may run multiple instances of Phabricator -- and we already built all the HTTP stuff anyway.

(I think that --not construct is wrong, and we'd just have to enumerate every branch explicitly.)

It's also possible that we can run git log --all --format='%H %P' and git for-each-ref and implement --contains ourselves in less than 2 seconds in PHP, although this is hugely ridiculous and clearly a problem with Git if true.