Feel free to file a new report if you are able to come up with clear, working reproduction steps that reproduce this issue on a clean install.

Thanks for catching this, and for the clear reproduction steps.

I think the way the view gets built is a little odd and I didn't get the logic quite right. Definitely a bug, thanks.

@20after4 : Ah. So by default, everyone just gets a "create task" option, which would never use any custom forms or subtypes. That does seem to resolve my concerns (although I still think it would be cool for phab to behave differently depending on which project(s) I was viewing).

@ksmith: Thanks to the new 'favorites' menu, each user can customize their menu, there is no longer a global 'create new' menu, as it's been replaced.

Our phabricator instance (WMF) is shared by many(!) different projects and teams. If I understand the current proposal, all the subtypes and forms would be available to all users across all teams and projects, except where specific access is limited (e.g. security issues). I think that forces us to either: a) have very few subtypes, which manage to achieve consensus, or b) have a lot of subtypes, which would mean that everyone's "create new" menu would be very cluttered.

In T12314#213245, @epriestley wrote:

Weakness: Subtyping is Probably Only Useful in Maniphest

Subtyping is likely to involve a large number of changes in shared infrastructure (EditEngine), but they will probably only ever be useful in Maniphest. Although most applications now use EditEngine, I can't really come up with any good use cases for subtyping in other applications. Perhaps Calendar could use subtyping on events, but this feels like a solution searching for a problem.

Thanks a lot for this ultra-fast reaction & fix.

This should be resolved at HEAD of master, thanks for the report!

I was able to reproduce it, sorry for mis-reading.

In T12347#214146, @eliaspro wrote:

Is it possible that symlinks could cause this issue?
libphutil and arcanist are symlinked from their current builds to the location where Phabricator expects to find them.

A basic version of this is now available in HEAD of master. Here's a walkthrough of what we've implemented and a discussion of some areas where we'd like feedback.

Go ahead and file something separate for that, I don't think it interacts here.

thanks, sounds great!

I think we've ended up in a fairly stable place here, and remaining work generally has existing tasks motivating it in terms of features (like T10967 for reviewers, T10574 for acceptance rules, T2543 for revision states, various tasks for inlines, T9713 for commit message parsing). Obsoleted transaction types also need migrations (but they should happen alongside the migrations that other features require so we're minimizing the number of weeks with migrations that need special planning) and this dumb mess got left in PhabricatorModularTransaction.php and will probably be there for an uncomfortably long time:

Sorry, I never tried to bother you.

Asking questions to the community first frees the developers up to fix bugs and make new features.

Thanks for the suggestion, we'll keep this task around if there is further interest we can always reopen.

Just to provide some more information, filling this feature request I realised that I like the fact that you have created two different forms (Bug and Feature Request) with the tags preassigned to avoid people "forgetting" to tag them.

Well it's not a real problem if you see like that. It was only a suggestion. Of course I can live without that.

This doesn't explain the root problem we require for feature requests. Please see Contributing Feature Requests and Describing Root Problems. We don't expect people to need to make so many forms, we don't know why you're creating so many forms, we don't know what number that is on say a weekly basis, and so forth. We also have upcoming products like Nuance that might be better suited for your workflow. Please please please... only file feature requests stating the problem (and not the solution) you are having with Phabricator.

(I've grown to like the icon-less menus though)

We'd probably be fine picking 16 per form... Not sure people customize forms outside of Maniphest though.

This is easy but I think you want to get rid of all the IconSet stuff and just let everything have any icon?

If you'd like us to look at it, please file a separate bug report with reproduction instructions, following the guide in Contributing Bug Reports.

I think this might have broken one of our Herald rules. The rule in question is an Object rule for Commits on a Project and will open an Audit whenever a commit is made to a repository that's tagged with this project.
At least it did ~2 month ago and after the upgrade it just won't fire. Just using the test console on a new commit in a repo tagged with the project simply says "Rule failed".
To make sure i already removed all the other conditions from it so it only states "always".

I'm going to dump everything into master now because I believe any disastrous brokenness should be reasonably easy to fix at this point.

So should Arcanist be modified to just call differential.revision.edit directly then?

From D17067:

FWIW #Twitter has multiple users of this feature and we'd likely get complaints if it broke

I do use it, but not in conjunction with preview.

Oh, there's no preference for this right now. I'll probably just keep "Z" for the moment.

JIRA actually seems fine: arc, web UI, and both the integrations (link / post) work properly for me at HEAD of master.