The behavior of TITLE and VISIBILITY are also wrong: they emit the current body text, not the body text at the time the change was made.

I think this is happening because both the "Title" and "Body" transactions are emitting text:

This should be ready to go with the deployment tomorrow:

Ah that makes sense, when I load a page on my iPhone (iOS 9.1) it shows desktop site and flashes down to mobile. I guess the server thinks I'm a desktop. Note this happens even on an iPhone 4s simulator (the oldest version I can run).

The 1-up renderer is server-side, it's not responsive CSS. Reload the page after you shrink.

I was able to repro on Mac OS X with a recent version of chrome.

I'm on iOS 9.2

In Safari/iOS I intermittently get the desktop site. No issues in Chrome.

That screenshot was taken as a 'logged out' user. There were two columns (so not unified diffs?)

iPhone 5s simulator

New blogs element is great :3

Oh, there are only two options and neither would break this.

Is Settings → Diff Preferences → Show Unified Diffs set to "On Small Screens" (the default) for you?

D14747 should fix this. I haven't pushed that yet, but I updated all the changelogs.

The URI scheme changed but this shouldn't fatal. I'll fix the fatal and then go fix the links in the changelogs, there are only like 6 of them or something.

Looks like the URL scheme migh thave just changed? I was able to get to the post by navigating to phame home: https://secure.phabricator.com/w/changelog/2015.49/

In T9908#148607, @epriestley wrote:

It doesn't seem to work properly if I try to comment and also change the status of a task. The comment appears but the task status remains unchanged.

I can't reproduce this. Does it reproduce for you on this install?

In T9908#148608, @chad wrote:

A minor usability issue as well... If you click on the "Add Action" drop down and continually press the down key then you end up adding every action. Maybe we can just disable this behavior?

This doesn't reproduce for me, can you provide more details? It just goes down the select list (and I have to hit <enter> to make it trigger)

I think this should now be fixed in HEAD. Let us know if we missed anything, and thanks for the report.

A minor usability issue as well... If you click on the "Add Action" drop down and continually press the down key then you end up adding every action. Maybe we can just disable this behavior?

It doesn't seem to work properly if I try to comment and also change the status of a task. The comment appears but the task status remains unchanged.

I noticed a few minor issues after deploying this on our install.

Without steps to reproduce the issue, what specifically do you suggest we do with this ticket?

In T9966#148595, @epriestley wrote:

So you haven't actually reproduced this yourself? Is it possible that the user mistook xxxxx as uncensored credentials? Can you try reproducing it directly?

I can't reproduce this locally even with a username email.

That prioritization makes sense to me. It doesn't seem worth putting a lot of effort into optimizing the workflow for a bad configuration.

So you haven't actually reproduced this yourself? Is it possible that the user mistook xxxxx as uncensored credentials? Can you try reproducing it directly?

I should note that we're running the latest version of Git (2.6.3) which could be the culprit. From my superficial inspection of the code, it appears that the output of git fetch is simply reflected.

In T9966#148590, @epriestley wrote:

In your report, you say <user email address> -- is the login username for this user a string including "@"? Does the UI print out a message like this?

https://xxxxx@domain.com:password@remote.example.com/...

..that is, the beginning of the email address is censored, but the rest of it is not and the password and domain are not? Or is the HTTP username not really an email address?

I should note that we're running the latest version of Git (2.6.3) which could be the culprit. From my superficial inspection of the code, it appears that the output of git fetch is simply reflected.

In your report, you say <user email address> -- is the login username for this user a string including "@"? Does the UI print out a message like this?

Until we have such a tool, you can revoke keys like this:

I think this is worth improving. However, I think it is not a very important feature in situations where things are set up reasonably well (not too many lint false positives, fairly fast tests or server-side CI), and that fixing these problems will have a lot of other benefits in cases where they aren't working well. That is, this should be more like a "nice-to-have" that saves you a few seconds once a week, not something you're hitting on >50% of revisions.

I may have wanted to say "set loose"... :)

Can I set looks an intern on this?

Right - I've miss-read the title.

Although timeline is now linked, I think feed still isn't linked?

I was able to get some metrics for how many revisions have lint errors in this particular project (repo callsign 'C') with this query:

What version of Phabricator are you running? (You can find this in Config → Versions for recent versions.)

Do you have the public key (or the private key), or do you just know which user has a compromised key but not know which key is compromised?

I can't reproduce that. Here's a search using "Path", which seems to work correctly:

You might already know, but I noticed that the owners search is broken if I use "path" instead of "Repositories" to query. Also it would be great if we can use the package name to search.

@epriestley can this information (branched from master) be exposed via conduit as well? Seems like a simple addition to differential.query

This request does not describe a root problem.

Awesome, good to hear.

Yep, that did the trick for me. Sometimes your are just to blind to see. Thank you guys for your help. Phabricator works now perfectly.

I'd focus on getting the user access to create databases, you'll want it in the future as well to streamline updates.

Tried this Installation Guide, and it worked until the point where you have to do the Database upgrade. But it seems like the database user from Plesk (create for phabricator with full permission, thats what plesk told) has no permission to create new Databases.

Also our documentation is way more hilarious.

(there should be no reason to create databases by hand)

We only support installation from our guide, other guides may be out of date or inaccurate in general.

@avivey followed an instruction from a plesk forum.
@chad not 100% sure if it counts as a shared host. I'm installing on a VPS with Root.

Are you installing Phabricator on a shared host?

In T9962#148505, @AleisterWeber wrote:

Added the Databases from ./bin/storage databases by hand in Plesk

Added the Databases from ./bin/storage databases by hand in Plesk