This doesn't describe a use case (per Contributing Feature Requests) except by reference to requiring projects (which is covered by T6030).

At HEAD, you can now edit this field via the owners.edit Conduit API method.

No clue how to reproduce. If you see it again, grab the field value too? My guess is that it's something like the reviewer PHID ending up as the project PHID instead of your PHID and "Reviewer" needing to be updated to "Reviewers" or similar.

This is related to T5158, I'm going to split things up like this:

Ah, I figured out how to reproduce this.

I think it wasn't that bad thanks to a similar set of changes elsewhere from D14669, which I wrote yesterday.

Oh, I should have read that comment more carefully. You tested more thoroughly than I did.

This no longer reproduces for me at HEAD in EditEngine (see T9905), although I can't immediately reproduce it in the old editor either. Since it seems like it got fixed somewhere I'm not going to worry about it too much.

That is hypothetical, but for example, lets say Evan publishes a post with the following:
/blog/750/development_notes_2015_week_494949494949494/
but really meant for the slug to be
/blog/750/development_notes_2015_week_49/

Isn't that a hypothetical?

The easiest thing I can think of is simple typos/ bad c&p job

How are you expecting bad urls to get generated?

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

In T9908#147036, @epriestley wrote:

Maniphest currently has field-level edit permissions (e.g., "Can Edit Task Status", "Can Assign Tasks"). My belief is that these are essentially always used to hide fields in order to simplify interfaces, not as real policy controls to prevent changes, per se. I would like to remove them entirely: I think they add a lot of complexity and are very difficult to explain to the user, particularly on the email and Herald flows. Broadly, I don't want to move toward a future where every field in every application has a per-field edit policy.

I have a concern about the /blog/<postid>/ignored_post_title/ approach, if the blog is indexed by Google, /blog/<postid>/ignored_post_title/ and /blog/<postid>/derpa/ will have the exact same content which Google penalizes.

Can't reproduce anything here, with Workboards/Mobile. If this was a real bug report, please follow Contributing Bug Reports and re-open.

We use SNI and nobody says it's bad. Hell, people actually WANT SNI, since when hositng fo example small shop, you basically need SSL (even cheap one), but IP address (especially IPv4) is pricey per month. Most people when faced with "additional $$$/month with only benefit being customers using ancient software" or "0/month additional charges, only lose handfull of ancient software-using customers" chose 0/month 😉

(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:

ah yeah thats good enough

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

Also, I need to fix this:

is it relatively easy to do with routes, something like /b/blog_title/blog_post/

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:

@epriestley, not sure you are aware of this but the "create dropdown" (big "+" in navbar) still point manifest task to the default form.

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?

whooop

Are you testing Phabricator or trying to file a bug?

I should probably add a subscriber setting for posts too, though.

Ah sorry, thanks for the clarification. I also just remembered that it's still prototype.

You have blogs set to ignore subscriber changes, not posts (not really a setting for that).

These new features are exciting!

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.

(consistent edit endpoints in Conduit and custom task forms are what I'm most looking forward to)