Please follow the instructions in Contributing Bug Reports. This is not a valid report without version information and step by step reproduction information.

who can help me?

Perhaps in a separate change, it would be nice to maybe show the application name under the more modern document types -- for example, show "Diffusion" here:

To reach this dialog, mash some text into the search field in the global menu bar, then hit enter.

This was resolved in conjunction with T8952.

I believe this was resolved as part of T8952:

To build on what was originally suggested, you can have all your repos stop publishing events by running the following which will list all repos and put them back to importing mode so they don't publish events:

I agree with that (and actually believed we already did that, see T11485 for me claiming that this is the current behavior). We'll change this.

@chad, what is the rationale behind processing the very first line of the git commit message (the title)? I can't find any reason to do so, the first line is always the title. If you just ignored the first line and not performed any extra arc processing, this issue would go away. What am I missing?

We haven't seen other reports of similar issues and can't reproduce this issue ourselves in a variety of production and development environments.

I'm going to close this since it's working as intended and was just based on a miscommunication -- the actions UI (above the comment text area) is not expected to show a preview of the effects of a change. Instead, the preview UI (below the comment text area) shows this preview information.

Have you fully read Contributing Bug Reports? This ticket is missing most of what is required for a handling, primarily reproduction steps, as highlighted there.

I've now tried on MySQL 5.6.27 instead of MariaDB. The same thing - cannot create a project. This time the process results in 504 Gateway Time-out. I guess if I'm the only person reporting this issue, the problem might lie with my setup. What's puzzling my is that it's only with the projects. 60sec should be enough for the FPM to process this request, I guess. Thanks for looking into it.

Oh, Complete!

root@ip:/var/www/issues# cd phabricator/
root@ip:/var/www/issues/phabricator# git pull origin master
From https://github.com/phacility/phabricator

• branch master -> FETCH_HEAD

Already up-to-date.
root@ip:/var/www/issues/phabricator# cd ../libphutil/
root@ip:/var/www/issues/libphutil# git pull origin master
From https://github.com/phacility/libphutil

• branch master -> FETCH_HEAD

Already up-to-date.
root@ip:/var/www/issues/libphutil# cd ../arcanist/
root@ip:/var/www/issues/arcanist# git pull origin master
From https://github.com/phacility/arcanist

• branch master -> FETCH_HEAD

Already up-to-date.

You shouldn't need to edit code, just update Phabricator. https://secure.phabricator.com/book/phabricator/article/upgrading/

I can't reproduce this. Here's what I did:

I using git master. and i did edit code to https://secure.phabricator.com/diffusion/P/browse/master/src/applications/config/controller/PhabricatorConfigListController.php;f379858874a3336dc36cc8b7e77b0d0b698b2fff$54 and error not complete.

Going to assume you are not up to date.

What version of Phabricator are you using? This should have already been resolved at HEAD of master.

Well, I'm guessing overall, roughy my theory is:

This is expected, as they are most likely not previously discovered commits.

This should be resolved at HEAD of master. Thanks for the report and the detailed analysis of the issue.

D15133 (making array utility functions accept any array-like object) is a possible attack on this in the general case, but I'm just going to fix this narrowly for now since it hasn't been a frequent/common/recurring problem so far. A more general approach may be warranted in the longer run.

The fatals should be fixed in HEAD of master. I'm going to retarget this task to clean up the actual method calls, but this should have no user-facing impact.

D16420 restores setIcon() as an alias of setStatusIcon() as a quick fix for the immediate issue, since I found at least two other affected interfaces (Drydock, Almanac) and am not confident there aren't more.

This was likely broken by D16418. I think setStatusIcon() provides equivalent functionality, let me take a look.

Yes, this is intended behavior. See T10262 for discussion. See T10262#158198 for comparison to other systems, many of which use the same approach to access control for the same reasons.

Same issue here

This is intentional (and not a security issue), the URI contains a security token valid for 30 days (or until the policy is changed).

Sorry, I was responding primarily to @chad there -- the preview is at the bottom. I've circled what I was talking about here:

(I believe we already show any changes that pressing the submit button will make to subscribers accurately in the preview. This wasn't always true prior to EditEngine and I think the preview/actual effect would sometimes disagree in weird cases, but I believe the preview is now always fully accurate. However, it's quite easy to miss.)

When a user writes a Maniphest comment, I think fully and correctly populating the "Change Subscribers" field, including its new/upcoming additions, would be a good and unobjectionable feature. This would allow the currently unconditional additions to be removed manually prior to form submission. This would still be tedious, but at least I could make a comment without having to either mangle the quote or go back after commenting to perform a separate manual action unsubscribing the user that I didn't intend to add.

Arcanist is the command line tool for Phabricator. You should have installed it when you installed Phabricator.

You should install arc. arc is the script in arcanist/bin/arc

I am so sorry, if my comments look a little bit "dumb".

In T11471#190152, @epriestley wrote:

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

[...]

You'll need to run arc liberate to pick up the new file so Phabricator can find it or put it in src/extensions. Then if you're an admin, go into Settings -> Global Default Settings, and change the install language there.

No i realized, that the File with the translation has to go to the "/root/libphutil/src/extensions" Folder, some Values are translated in the ui, but others aren't. Is there a file, where i can find all strings, to translate it? Or is there another way to find out how to translate a specific string?

My bad I didn't see the second comment by @chad. I know it is possible as @epriestley changed the language of this instance (see D16310#190724).

Let me add some note: A changing of the "Translation" - Dropdown in the individual account settings never makes a change. So it is not important if i choose german or something else. That is not influencing my request, but is that a normal behaviour? Or did i maybe make a mistake when i set up the system?

This is the full code of the file in my case.

Do you mean the patch, added by devurandom ? The first part of the patch ($default...) is not existing in my PhabricatorAccountSettingsPanel.php

Does T8916 help?

If you don't like the @mention-implies-CC behavior

This is not a demo bug tracker. Please Close this task and go to https://admin.phacility.com/auth/register/ to create a demo account for free.

https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/js/core/behavior-form.js:57
looks like it's supposed to be listening to submit, but there's no submit event being fired while in a dialog; It does fire when the same dialog is loaded as a full-page, so some magic is happening there.

.aphront-form-input input is to blame.

I'm also seeing this for failed builds:

Resolved by D16415.

I'm going to upload a patch in a few minutes (I can't claim the task :-/).