Awesome.. Thanks!

I pushed this to HEAD of master, we'll cherry-pick it shortly to stable.

This is fixed in D18189.

https://secure.phabricator.com/book/phabricator/article/diffusion_autoclose/

One problem with forking Phabricator is that we would like to keep the code in our internal Phabricator. In this case our internal Phabricator react at the commits pushed on the external Phabricator.
For example if in the external phabricator there is a commit message contains fix {Txxxx}, it will close our internal ticket with no {Txxxx}. Is there a way to tell Phabricator to not react on specific repositories?

The page implies that all I should need to do is POST up, for example, the following:

Can you point me at where that's implied so I can make it more clear? That isn't currently expected to work. ... We do not currently support a blob of JSON as the post body, and the documentation shouldn't imply that we do (if it does, I'll fix it).

Methinks that the Rube Goldberg solution for this would be to get unittest.skip to have another argument with a task number, and then validate with lint/runtime that it look like T1234. And then maybe grep the body of the ticket for the filename.

Can you change the syntax to something like @unittest.skip("Reasoning behind this decision...")?

One thing I should add is that your different application tiers should be different stacks: i.e. DNS config should be one stack, web boxes another stack, DB another etc.

That is, I think the right tool for the job is either runtime enforcement or lint enforcement: make unittest.skip() with no reason fail (so the tests don't pass) or make lint raise a warning like "unittest.skip() must have a comment above it explaining the plan for re-enabling the test.".

Can you change the syntax to something like @unittest.skip("Reasoning behind this decision...")?

I know about T9853, but if there's still a chance you might consider merging that upstream, there are a few folks here at Khan Academy who are excited by the feature. Here's one example:

I don't have any great thoughts here. I'd dig into MySQL and see what limits might be getting reached that it's turning away connections. I presume you did not set up clustering in the database? Unclear what "I even only have one master an replicas." means.

This is either T10333 or T4863. I'd guess the former will happen first. Filter is probably the best workaround until then. See also T12374 maybe, although I think that task involved a lot of meandering.

Notes for myself about billing:

Admins can fork Phabricator and provide whatever styles and options they like.

I understand. But it would be nice to let the administrator to choose the best width limit for the all team.

I can supply more information, if Iknow what is necessary. But let me try to clarify the issue.

To take a step back, the upstream has exceedingly limited "free support" resources. So in exchange for providing free support, we simply as users to read and follow guidelines before submission. This reduces support overhead on the upstream and means more time can be spent both providing support to other users or by developing new features. There are more detailed discussions on how we can continue "free support" and "paid support" under T9212 and T12681.

And wow on your reply. Just ... wow.

The document I linked (and also on the form you filled out for reporting a bug) state the requirements on what's required for a bug report. I marked this as invalid and directed you to a document on how to resolve it.

@chad It's more helpful. If you would have a template instead of a page long instruction.
+ If you tag it as invalid, it's also nice why it is invalid. I provided versions and logs.
+ if you leave user alone with her/his problems, they lose wish to use it.

Please read and follow Contributing Bug Reports.

Is there a way to exclude users/projects from a query? A user on our install has asked for a way to search for Differential revisions with Project X as a reviewer where the author is not a member of Project X.

I get the same error after delete project by "bin/remove destory phid". I find that the phid has been removed from edge table in mysql but the phid exist in project table. so I delete the phid project record in project table just resovle it

This information may be entirely useless, but it is somewhat related. We have a large number of repositories, with multiple clusters so this affects us in a major way.

bin/audit delete --users employeewhonolongerlovesus

Yeah, you should be able to use diffusion.commit.search (with the authors constraint) + diffusion.commit.edit to accept/close the commits.

I would accept to have to issue some very long winded command on the console...

Have you actually tested this scenario yourself?

Thanks Evan,
while I perfectly understand your point in sharing that link with me that's not an applicable option: I am evaluating a code review solution and I initially fall in love with Phabricator, so much I've started a large scale PoC, which is where I currently am.
Sadly, either I failed to understand the real capabilities of this suite, or the suite is not fit for our needs. In any case, I don't have a budget for this PoC other than my team time, meaning I cannot take your suggestion into consideration and I also don't think it would be practical as part of a PoC.

In T12901#228807, @epriestley wrote:

Edit the Saved Query to contain something sensitive

This isn't possible.

See Consulting if you'd like immediate help with this issue.

Edit the Saved Query to contain something sensitive

I don't know if this is still being worked, but I find myself in a tough situation: I have a team member which has 1k+ audits, but he has recently resigned and I don't see an easy way to remove that person from each and every audit he has been assigned to!

In T12901#228799, @epriestley wrote:

A user might have a saved query which contains sensitive information no one else should know about.

How would other users discover the query's ID?

From elsewhere:

A user might have a saved query which contains sensitive information no one else should know about.

That use case doesn't strike me as compelling enough to justify a separate field or a behavioral change so I don't plan to adjust our behavior here.

In T12900#228746, @epriestley wrote:

Only you and users who have permission to edit <Blog Name> can see this draft until it is published. Use "Publish" to publish this post.

...would that resolve things in your case? Or does the rule we actually implement not work as well as "only the author" in your use case?

Also related: T12417: Show failing status of Diffusion repositories in top main menu bar.

It's not something we'll support given the cost and lack of interest. You can either fork and provide the feature for your local install or use a supported method of connection. To be honest, this is the first request I've seen in 5 years.

We've also had a request for this (disabling the in-application popups) at #dropbox, as a per-user preference.

+1 that this is needed and complements T5474.

+1 that this is really needed.

@hach-que thanks for the suggestion. I've used CloudFormation with some success previously. My biggest problem is occasionally having a stack just get "stuck" while deploying, and taking forever to timeout on a failure. I've also seen very ambiguous error messages when some random resource fails to deploy, but these are all just anecdotes. I'm working on a demo CF config to give it a try.

You must be able to view a post's blog to view the post, so the rule is effectively "view and edit".

Don't most places consider "Can Edit" to be weaker than "Can View"?

One of our engineers is having a similar issue with slightly different error, running "arc install-certificate" would always fail with the following error: