You probably need to configure Apache to correctly route the web sockets.

In T10783#170004, @hach-que wrote:

Otherwise I have no idea if your Apache load balancer is interfering with the connection.

Yeah that Docker instance is maintained by me. It's not intended to sit behind any kind of load balancing though (unless you're routing WebSockets directly to the client). Otherwise I have no idea if your Apache load balancer is interfering with the connection.

Yeah, you'll want to open one bug report per issue.

That would be one ticket for each of

The design intent was to give more space and prominence to the title of the task, and the discussion, and this is what's important 9/10 visits to a task page. Meta-data like tags, dates, author, assignee were moved as while these are important, you only likely reference them on very rare occasions. I don't believe this pattern in the general case to be unintuitive, since the design solves the problem reasonably well. It's also the same pattern other issue trackers like GitHub use, so it's one people are certainly familiar with. As with anything of course, it's a trade off. Whats best for most installs might not work best for you, and we're happy to try to understand what that might be to make Phabricator better.

@chad, don't worry, I understood that it's important for you to have clear input from users and that's why I apologize for being unclear with my request. Moreover, as you say, this is pretty superficial and we can maintain it on our local install. But as it was the general return from our users (unintuitive UI), I thought it could be reported to upstream.

Yeah, you'll want to open one bug report per issue. Also, installations via third party installers are not supported and aren't considered a valid means to reproduce the issue. You may use a Phacility test instance if you want an easy, clean, reproducible installation quickly built.

The main reason we ask for root problems or "why" is so we can determine what's the right way to solve the problem. So knowing why that information is useful, how often you need to reference it, and what decisions you make because of it, is important for us to determine a solution.

Mainly because this is one of the main component of a task (ie, what defines a task). But actually, this is something which could be customized on our side. Sorry for bothering you and being unclear about the request. I think you can close this task.

I suppose custom fields could be used but the major issue is in retrieving the information about revisions/commits being on branch X. Documentation is lacking and I couldn't find out how Diffusion populates the Branches field. Any pointers?

Some additional cases with this:

and assigned to seems to be an essential information

Sorry, I read the "Describing Root Problem" and I thought that explaining the main problem (not intuitive for users and lack of visibility for Assigned to and Authored By) was sufficient.
The problem is that users ( at least ours) want to find all essential information (and assigned to seems to be an essential information) in the same place by taking a quick look at the task such as for priority and status.

In T4181#161779, @sevendays wrote:

@sinayion don't start the phd service before mysql. The daemons need the database to be active.
I'd start phd after http and mysql are up and running.

We should probably substitute in "Unknown Ghost" then.

Looks purposely set to VOID in the migration, maybe this information isn't recoverable historically.

Is is a mitigating factor that the PawLIB [Project] has six Subprojects? They all work correctly. I didn't think of it at the time, but maybe that has the project membership subtleties mixed up.

Oh criminey, that should have duplicated. Those are nearly exact same steps I followed on my local copy, but I get this:

Specifically I took these steps.

Can you clarify the steps to reproduce, specifically the first step. This doesn't reproduce for me.

An E_PERM panel seems reasonable here, but I'd like to add a use case for hiding.

Authored by is precisely in the same place it was previously, which is the first transaction in timeline. As an additional, new feature, it was also placed in the side column.

This request does not describe a root problem; instead, it asks for a specific feature. See Describing Root Problems for help.

Progress so far:

Looks like D15680 worked.

lies

Hrrm, that's buggy.

T6996 is adjacent.

This report does not appear to describe a bug in Phabricator, and does not include version information or reproduction steps.

Thanks for suggestion guys. Will do the workaround.

As a workaround you can create credentials in Passphrase, then select the credential and click "Continue"

I dug everything up here.

This bug report is missing version information and reproduction steps. Please take the time to file a complete bug report and re-open after. Thanks!

Technically, the feed story is correct.