Yeah, these two bugs are probably connected. But the reproductions steps in my setup are surely more common 😄 When I tried to setup the main dashboard for our install, we changed the tabs a lot of times to find the right way to present the important infos for our users. This swallowing of tabs was pretty frustrating...

Duplicate of T12363: Configuration of "Tab Panel" is lost when 1st tab has no panel assigned

Filed T12707 to follow up.

I don't expect watchers to be on profile, but we should provide a search for it in /projects/

Another anecdote explaining that the current situation is confusing:
As a user who has not been active in Phabricator for a while and as my interests in projects might have shifted, I am trying to find out why I receive email notifications about certain tasks and how to disable these specific notifications to reduce the amount of uninteresting mail. But:

• My "Profile" user page does not list any "Projects".
• The email headers do not tell me either why I received an email.

After some thinking I realized that the reason was that I was a watcher (but not a member) of an associated project tag of a task.
I'd expect my "Profile" user page to not only list "Projects" (actually means: Member) but also projects that I only watch. Currently I need to go to one of the tasks that I received an email about, click all associated projects, and go to the "Members and Watchers" page of each project to find out that I once added myself as a "watcher" and remove myself.
However, that might still not explain why I received a specific email: If I have "Settings > Email > Email Preferences > Maniphest Tasks > One of a task's subtasks changes status" enabled, I also need to check all subtasks' projects whether I watch one of them.

Not sure if I should make a separate issue for this or just mention it here, but it would be nice if you could parse the "signature" of a patch generated with git format-patch. Currently patches generated with git format-patch cannot even be uploaded to Phabricator unless you set git config format.signature=""

BTW, the original patch was generated using git format-patch, not git diff

The original patch which causes this problem is attached. It was generated using git version 2.10.1.windows.1. git am 0001-Move-lld-Parallel-algorithms-to-llvm.patch will successfully apply the patch, but after uploading it to phabricator and then redownloading the raw diff, it no longer applies. The original patch contains text like this:

I don't think this is about inline comments, since @ajklen says "comment dropdown menu" and inline comments don't have one. I believe they want this, in the existing dropdown menu of (non-inline) comments:

Sorry, to clarify, I'm just asking for a convenience feature in the UI. I'm aware of the History tab, but I find that I often specifically want to see changes made since a certain comment (e.g. to check if/how the issue was addressed). In other code review software I've used, this workflow only takes a single click.

I think the author is essentially asking for an easy way to map inline comments to the diff that they were originally made upon.

No. It's not that the builds can access credentials on the build hosts -- that part is a general problem -- it's that the Phabricator application hosts can be made to divulge their credentials (which are necessarily the same as the S3 credentials, because the same hosts must access S3) by instructing them to run builds that use 169.254.169.254 as a "build server".

In T5155#223416, @epriestley wrote:

As a general note here, we've been vulnerable to credential theft from the local service throughout this discussion, and still are until T12701 resolves: attackers can create a Harbormaster build plan which sends requests to 169.254.169.254, then read credentials from the output of the "failed build".

(We don't take UI feedback as feature requests, for the record).

Are you referring to this table here, which already exists or is there another problem you're trying to solve. It's unclear if you just have a question on how to use Phabricator or are asking for that workflow to be more efficient.

Go to Applications and click configure next to maniphest. You can assign an email to catch bugs@

Hi @maxie, do you know how to setup Phabricator to create tasks sent to bugs@domain.ltd? I have finished everything as described in the manual, but I receive this:

I think this is generally reasonable, but probably on the far side of T12010 since it implies API changes.

Users can also currently add http://169.254.169.254/ as a Git repository, although I'm not certain if they can actually capture credentials by doing this.

As a general note here, we've been vulnerable to credential theft from the local service throughout this discussion, and still are until T12701 resolves: attackers can create a Harbormaster build plan which sends requests to 169.254.169.254, then read credentials from the output of the "failed build".

T11632 is vaguely related.

Oh, no problem -- we likely won't look into this for a while anyway (T12664 is a big mess of related issues that we'll probably try to fix all at once).

Sorry, I've been slacking on getting you this information. Been swamped at
work. I'll try to get it to you this weekend.

See Contributing Feature Requests, but also note that we're likely to restrict this channel soon because no one reads that document (see T12134#212579).

(We probably won't look at this until T12664 moves forward, but when it does it would definitely be helpful to have a specific set of steps we can take to reproduce the issue locally in a clean repository.)

I don't think this is a bug: both systems are behaving as designed.

Isn't that a dup of T8611?

This is not a demo or test install. Please don't make a mess! You can launch a demo install on Phacility if you want to poke around and try things out.

Hey guys,

Thanks for link, i know that page already. This feature is the one missing for us to switch from another well-known system which have more and more performance and billing problems.
That means we can finish the development of this one : that's why i asked for a status, rather than a boring "will it be ready next week" :)

See Planning.

I just applied the patch (roughly) and the "edit" pen appeared in Phrequent. By the way, clicking on it lead to a 404 Not Found error page.

any news here? the implementation seemed on a good way but there was no update since July 2015

This is rather strange. I don't have the original patch used to create the revision anymore, but I tried it again using the same command I always use to generate patches, and when I upload this new patch, I do not see the same issue. In the first (broken) one, some of the files are marked with V, but in the new (working) one, none of the files are marked as V. This is even though git status shows that they are renames:

Which version of git was used? Can you upload the original patch file used to create the diff?
Which version of git is the server using?

Note that a workaround is to do the following:

Excellent! Thanks @avivey.
This ticket could be closed.

@epriestley Whoops! So embarrassed. Thanks :)

You're on the wrong install by mistake.

You're on the wrong install by mistake.

You're on the wrong install by mistake.

I think you've filed this against the wrong install by mistake.

It saves it to a directory called arc in your repository meta-directory. If you're using git, it would be in .git/arc/.

Thanks for your reply.

You can user arc set-config --local to set a configuration value in a file that is in the repository but is not committed.