I don't plan to support this. I think "files attached to any object tagged with this project" is not likely to be a useful view in most situations, and haven't seen other requests for this. We inched into this territory with a "files" module in Conpherence some time ago and it was felt pretty much useless in practice.

As a workaround, you may be able to use the API (maniphest.edit) to, e.g., have a bot or script post comments to tasks.

I think this feature is far too niche (use of git describe is rare in the wild) and crude (it doesn't actually tell you information about deployment status, and you don't actually use the raw git describe output, and the output is not necessarily related to the build) to bring upstream. We also already link up the commit, which shows branches, which usually provide some related information in standard setups.

If disabling a user removed all policy controls, an attacker who compromised an administrative account (or a malicious administrator) could disable other users and then access information they could not otherwise see.

The most recent ruleset seems to be working pretty well for me. It hasn't been spazzing out and popping up all over the place, but has been there the couple of times I actually wanted it.

See also T9853, which includes an extension to do this.

This is an amorphous, unfocused task and substantially resolved by profile menus and changes in HEAD or planned in connection with T10054, see also M1450.

See T10180 for additional guidance.

"Subscribe" has been removed entirely, primarily to clarify this distinction. The intent and effect of "Watch" is also now more clear. There is additional guidance available in T10180.

This is now resolved, and you no longer need to be a member of a project to watch it. T10180 has additional guidance about this and related changes.

This does not describe a root problem. See Contributing Feature Requests and Describing Root Problems.

This has been quiet for a while, seems like nothing broke too heavily.

As I recall, yes. But the only install I'm aware of that uses it (Asana itself) also disables the mail prefix, and might disable subject variance, although I'm not sure.

It makes more sense to use the mail message title in Asana, as the integration is essentially replacing mail. It makes less sense to use it in JIRA, and the object's handle's full name is probably the right string to use. I think it's probably OK to just use that universally.

You can remove the prefix with metamta.differential.subject-prefix, and remove the action with metamta.vary-subjects, but both of these will also affect mail.

Oh, you're translating Audit. That's why it says "Accept Commit". I thought you were translating Differential, sorry. Everything else should work in Audit.

• JSON does not use "\x" escapes. See https://json.org/
• The untranslated text is "Accept Revision ✔", I'm not sure why yours says "Accept Commit ✔".
• This config value:

To clarify, you can put anything you want in a project name. Only hashtags have character restrictions. ??? Whales! ??? ~(BIG WHALES)~ is a completely legitimate project name, and will be forever.

You can now add links to wiki pages, conpherences, etc., to the sidebar.

Specifically, the issue was that these commits contained strings like R2/R13, which the parser was getting confused about because of an improperly grouped regular expression.

This should be fixed by D15049. Thanks for the detailed reproduction instructions, including a repository I could clone locally.

What device are you using, and what is the screen resolution of your device?

• D15045 fixes the problem with "Additional Hashtags" getting smushed.
• D15048 fixes a problem where removing old, invalid "Additional Hashtags" could fail.
• D15047 should fix old hashtags 404'ing.

The mitigation was applied to remaining nodes on Jan 16, and everything was also upgraded to OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.4, OpenSSL 1.0.1f 6 Jan 2014, which is the Ubuntu upstream fix for the issue.

If the acceptation of only one blocking reviewer among all of them is enough to consider the revision as accepted, I don't need this feature anymore.

Presuming resolved by D15030.

{ "http": true, "https": true, "mailto": true, "tel": true }

In T10163#154334, @cspeckmim wrote:

I like that idea. Should it also hide if there are 0-1 matches? When mentioning users with short usernames or project names it's often faster to just type, @chad, @cspeck, #enad, etc.

Okay, all that stuff is live now too.

I didn't do that because I don't think a space is universal -- I've seen ":" and ",", particularly.