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:

Historically, Phame originally used the claimed rule ("only the author"), introduced in or around D3694.

The rule we implement seems to work properly, but the UI tells you a different rule.

The language here is inconsistent with the rule we attempt to implement. Let me make sure the rule we attempt to implement actually works and that this is just a language issue.

If other workflows means pushing to the remote, T5000 is the plan. Functionally we don't feel " just push whatever" to the remote scales once you hit enterprise scale. The remote becomes polluted with junk branches.

@chad Do you have any hint for me how to configure a socket database connection

Thanks for the link. That's rather conceptual though. And things like overriding upstream landing is a thing that breaks compatibility with underlying SCM by assuming you use arc-feature. A tool specific explanation of the workflow would be great, for understanding the point of why things work the way they do. Though I'd rather the Official Workflow did not prevent other workflows. But I guess I have the power to remove that feature.

Alternately, follow T5000 for a non arcanist workflow.

@chad: arc-patch requires a diff and pushing a branch is much simpler than creating a diff. Since we seem to be pushed into the direction of an official Phabricator workflow, is that documented somewhere? Phabricator makes assumptions about code structure, versioning and many kinds of things, but are they stated somewhere?

It's abnormal in Phabricator. I use arc patch to work from multiple machines.

Severely needed. .arcconfig should be able to control where things land without arguments. I also question the choice made in D10058 where branch tracking seems to be used as a indicator of a branch created with arc-feature. Since arc-feature is in no way central to arc use, I think it should not be assumed that it will be used. And regular workflows and GUI tools will use git-branch instead, with tracking.

This is a problem for us too. People push branches to work on it on another machine.