I think we should wait until we implement T8060. There will, undoubtedly be some javascript unpleasanstries that will influence the level of customization allowed for this. If we push the user preference patch now, the most inconvenient outcome is that there might be a need to split out format customizations into date selection control format and timestamp format, which is too much preference noise, if we can avoid it. The best outcome, as far as date selection controls go, would be if we can improve and simplify the date selection control, then find a way for the user preference to be the master of both controls and timestamps.

I would probably punt on this until we pursue true internationalization.

My primary concern here is that I strongly dislike adding options to the product (see T8227 for discussion). In most cases, I personally bear the brunt of the long-term cost of adding options.

Yeah, we should probably remove this. T4103 will eventually allow global defaults to be set up.

This is probably one of the global/admin settings we should remove, not sure there is any value. The preference "Default" is displaying what the admin setting is (in this case, nothing) and CSS has control if neither of those are set.

This is technically correct.

The monospaced text also overflows:

In T5358#102327, @qgil wrote:

We are requesting a setting to allow our admins to disable Self Actions by default in our instance, because we know our community and this is what they are clearly asking for.

Linking this request to T4103 is conceptually correct, but here we are talking about a single system-wide binary setting that could be defined from the Configuration backend without any UI changes. T4103 encompasses a collection of rather rich features that will take a long time to start and complete, and that is currently prioritized as Wishlist. Maybe this was a way to say yes, but is pretty close to a no. :)

In T5358#101777, @epriestley wrote:

How about changing the entire product to default to not sending any email?

I brought this task again because we keep receiving feedback from our users against this approach, and I am genuinely interested in seeing whether you will get similar feedback channeled to you in your new role as Phacility hosting admins.

This feature didn't even exist in Phabricator until 2012 (see T228). For the entire time we were employed at Facebook (more or less, I guess you guys left a little later than me), no one complained about this or requested the ability to change the behavior. And the user who eventually complained is the #1 email hater of all time.

You listed JIRA and Workday as examples, and I think it's really important to not just list other software that does this, but to understand more specifically why. We haven't been in the practice of just adding features because x,y, or z company has them (pull requests, for example). Part of my concerns is getting to the very why of this feature in Phabricator. If that is well defined, then it's easy to either defend or debate/discuss if it's still worth having.

I'm not sure how come people don't think sending emails on self action ISN'T the default in most enterprise software...?

How about changing the entire product to default to not sending any email?

My concern with the current default (send self-actions) is that it's surprising and it gives preference to a specific developer workflow (one that could be opt-in, not opt-out). I do find the number of people who have switched it here specifically, high. If we flipped the setting, I'd guess less than 5% would opt-in. Is there other software that offers this feature?

I'm looking forward to see whether the successful launch of Phacility and the new instances being created shed some light here. I still suspect most new users get confused about this defaut setting, mostly because I don't think it is found by default in any other popular service.

Buddy, I had already been using that by tweaking the JSON file in the config,. Just wanted to know about your plans of introducing it in the application. Anyways, thanks for your help guys. I really appreciate this product and would continue to use it at our organization.

(I believe @fabe covered the main part of the feature request)

Please see https://secure.phabricator.com/book/phabricator/article/feedback/ if you are new to Phabricator. Historically, we're not likely to add features to Phabricator simply because they existed in another product a user liked. We have a very small unpaid team (3 people) and have a very focused way of building product. We're always happy to solve real problems, so if you state your problem, there is likely already some form of a solution already filed in most cases.

The maniphest.status config option allows you to specify any status as being treated as "closed".
Actually there is no single "closed" status. But resolved, invalid, spite & wontfix are all treated as closed.
Feel free to rename / change this properties to your liking and your preferred workflow.
What you describe would be somethink like:

{
  "open": {
    "name": "Open",
    "special": "default"
  },
  "resolved": {
    "name": "Resolved",
    "name.full": "Resolved",
    "closed": false,
    "prefixes": [
      "fix",
      "fixes",
      "fixed",
      "resolve",
      "resolves",
      "resolved"
    ],
    "suffixes": [
      "as resolved",
      "as fixed"
    ]
  },
  "closeresolved": {
    "name": "Resolved & Closed",
    "name.full": "Closed, Resolved",
    "closed": true,
    "special": "closed",
    "prefixes": [
      "closed",
      "closes",
      "close"
    ]
  },
  "wontfix": {
    "name": "Wontfix",
    "name.full": "Closed, Wontfix",
    "closed": true,
    "prefixes": [
      "wontfix",
      "wontfixes",
      "wontfixed"
    ],
    "suffixes": [
      "as wontfix"
    ]
  },
  "invalid": {
    "name": "Invalid",
    "name.full": "Closed, Invalid",
    "closed": true,
    "prefixes": [
      "invalidate",
      "invalidates",
      "invalidated"
    ],
    "suffixes": [
      "as invalid"
    ]
  },
  "duplicate": {
    "name": "Duplicate",
    "name.full": "Closed, Duplicate",
    "transaction.icon": "fa-times",
    "special": "duplicate",
    "closed": true
  },
  "spite": {
    "name": "Spite",
    "name.full": "Closed, Spite",
    "name.action": "Spited",
    "transaction.icon": "fa-thumbs-o-down",
    "silly": true,
    "closed": true,
    "prefixes": [
      "spite",
      "spites",
      "spited"
    ],
    "suffixes": [
      "out of spite",
      "as spite"
    ]
  }
}