I'm not sure this is a problem of Phabricator. It sounds like a problem of your LDAP conventions.

We'll consider adding a setup issue if we see other users having issues with this. Previously, we haven't, so we presume users having or uncommenting these blocks in the wild to be very rare.

I'd be OK with that. I already got our admin to resolve the problem for my install, so I only raised this thinking it would help others. A server configuration warning would also have worked to have me fix this before users encountered it.

The correct solution for us would be to detect the servers misconfiguration and raise a setup issue asking the admin to resolve.

You already gave one @chad, on Ubuntu if the sysadmin uncomments that section, then any link starting with .ht would be blocked.

In T10574#165181, @Luke081515.2 wrote:

In T4887#164619, @Luke081515.2 wrote:

Maybe a good idea too:

• What about if you can configure at owners, if the owners should added as (blocking) reviewers automatically? Makes this simple too.

In T10584#164866, @eadler wrote:

In T10584#164865, @avivey wrote:

GitHub actually encourages reviewers to "Add commits to PRs"; It's a little hard to un-teach once it gets hold.

one of the many reasons that the github pull request model is broken as designed :\

Also, we link to . files elsewhere in Phabricator, so if we change Project URLs, this webserver config would still break other parts of Phabricator, like linking to .gitignore in your repository.

This is what I see on Ubuntu for default conf files for nginx, it's both commented out and restricted to .ht:

It is extremely common to have nginx configuration

In T4887#164619, @Luke081515.2 wrote:

Maybe a good idea too:

• What about if you can configure at owners, if the owners should added as (blocking) reviewers automatically? Makes this simple too.

It has been common in http://www.mediawiki.org/wiki/Parsoid code development for reviewers to sometimes take over a patch, fix issues, or propose a different way of doing things. That sometimes seems faster and more efficient in terms of getting over tricky areas of code and working through different approaches / issues. It works out well for us because none of us mind that approach.

Ok, I was able to add the user to the project by adding him to one of the subprojects. I guess that works for us. Thanks for your help.

Oh, I totally misunderstood what you said.

I have also archived both subprojects in an attempt to workaround this and I still can't add users to the parent project.

Both subprojects are set to "All Users" for their permissions

I still can't add users to the parent project though

I was calling it a zombie because I couldn't join it or change any of the settings on it even though it said I had permissions to do so. Maybe not the best description.

What is a "zombie" subproject and how can we reproduce this?

Ok, I was able to join the subproject by setting permissions on the parent project to allow joining by "All Users"
I still can't add users to the parent project though

The original error message seems to be improved, btw, but I also seem to have a zombie subproject now.

Yeah, we still run into the same problem from time to time:
error: the patch applies to 'hadoop-scala/lib/driven-plugin-1.3.6-hosted-ga-11.jar' (49f50831fe1109b164f56c8e823132aa5f5171c9), which does not match the current contents.

Upgraded to 121e68e3 and the problem is still there

Oh and we're at 31984a78ee at the moment. I may run an upgrade here in a bit just to see if the newer version fixes anything.
It looks like any project with subprojects has the "Add Member" link grayed out.

Hi guys, any update on this? It looks like I can't add members to the parent project either so subprojects seems to be making a mess of things at the moment.

Interesting (and weird). Thanks for the update -- and good luck figuring things out.

Quick update here. We've found that adding FORCE INDEX (primary) results in 79.4ms in production even without the key_history index.

In T10262#165087, @swisspol wrote:

Naive question, but would it be possible to have a new "disable security theater" setting and have Phab then do "Unique URL Hash + Fully Cacheable Resources" like everyone else?

I'm not immediately able to get --create to bring up a template with "Differential Revision". Here's what I tried:

Sounds good to me. This is the first link that comes up (Tested in incognito) when you search for ERR_CLOSED: This revision has already been closed and the second when you search ERR_CLOSED so documenting it here may fix most peoples issues.

I think we should ideally try to be more clear about the issue when the user passes --create, even if something in range says "Differential Revision: Whatever". That said "a little bit before I look at it" has been like two years now. Let me spend like 5 minutes on it and if it's a big mess we can just write it off.

This should be safe to close as I think it's all user error.

Ran into this same issue today and seeing this had no resolution I went over and tried to debug what the actual cause was.

The issue you're experiencing is because you're out of date.

In some cases, the effects of the theater can be mitigated issue-by-issue. For example, we may be able to write caching/rendering logic in Javascript to mitigate the performance impact on lightboxes and Pholio. We may be able to attach images directly to email. There may be a workaround for the Safari issue, or we may be able to do preview rendering partially in Javascript. With Quicksand, we can also increase the "hit rate" of client-side Javascript caches, at the cost of additional complexity.

I imagine we also want to just remove the feature, but some install(s) rely on it? The point of this task then is to be a discussion around removing it outright, and giving those who rely on it time for input.

I spent like 20 minutes on this in the redesign and couldn't figure it out.

Understood. I'm of the very same opinion when it comes to adding settings / preferences to a product. It shouldn't be a way to avoid taking a decision or pushing the problem to the user.

I'm strongly resistant to that, see T8227.

Naive question, but would it be possible to have a new "disable security theater" setting and have Phab then do "Unique URL Hash + Fully Cacheable Resources" like everyone else?

Presume this resolved, an example query could be "Active Projects, Joined, with icon of Project or Experimental", or however you internally denoted actual Projects.

I've rebooted the Windows VM and haven't seen this issue in a few days. So we're good. Thanks for the help.

(That was a race, not me separately correcting the status, if it wasn't obvious.)

Truly, we have closed this task.

time well spent, @epriestley

That is a cool looking bug.

Specifically, you need to build your query in Projects, save it there, then build a panel for it in Dashboards. There are various tasks to better improve this UX.

@cburroughs: thank you

Just to clarity, that project tag is for the Dashboard Panel itself, not the query being ran.

either suggested changes based on our UX or ways to improve discoverability for functionality that already exists but that we did not discover

We do not support disabling Javascript and have no plans to improve Phabricator for users who intentionally disable Javascript. These users should enable Javascript if they want to use Phabricator.

@epriestley thanks for the detailed reply! I am now working with our DevOps person to change our configurations based on what you advise. Once we tackle all of this based on what you've mentioned, I'll update this task with examples (either suggested changes based on our UX or ways to improve discoverability for functionality that already exists but that we did not discover). Will be in touch in the coming days...

See also T3301, T8594, & T4558

General questions about using Phabricator are best in Ponder or IRC. If this is actually a bug report, you must provide full steps that we may locally reproduce the issue. Thanks!

by default, all search terms should be AND'ed instead of OR'ed

For completeness, note that this opens up a sliver of a DNS rebinding SSRF attack window (see T6755 and T6755#103700 in particular).

Before I forget:

Adjacent work:

OK, after installing all the necessary extensions and changing the php.ini as recommended by phabricator everything works nice.

Various notes from prototyping:

OK, I'm going to switch to php7 and see if it goes.

T10586 is likely a second case (similar to T7248) of a user without mysql or mysqli.

T9640 is tracking PHP7 compatibility. We haven't extensively tested Phabricator on PHP7 yet, but I believe several users are running it without any issues. We're happy to fix issues you encounter with PHP7 if you report them.

@epriestley that is from PHP 5.6.17

Is that output from the version of PHP with a problem, or from PHP 5.6.17?

The issue is not comming from missing php-extentions. mysqli was installed and present in fpm and cli so that was not the issue.
The actual function is missing, as @eadler said in the previous comment.

I understand that my description is not a root problem, but I don't know how I could make it clearer.

From the homepage:

Touché!

Here are a few use cases for experienced peers rebasing each other's commits:

• I am reviewing a patch which is OK but I don't like some detail like naming or code organization. It is somewhat subjective and a nontrivial effort to change, so I don't want to force the patch author to do extra work because of my personal preferences, but I am sufficiently annoyed by it that I am willing to do the extra work myself, so I ask them if it's OK for me to change that, and do it. The real work in the patch is still theirs, and so is the responsibility, so 'commandeer' sounds inappropriate.
• a patch needs some trivial change (easy rebase, comment typo fix etc), and the author is not immediately available (different timezone or maybe a volunteer who only has time on the weekends). Asking them to fix will cause unnecessary roundtrip delay and require the author to pay again the cost of resuming the context, setting up the developer environment etc. Also during the roundtrip time more code changes might be merged, requiring a less trivial rebase which might necessitate code review again. So it can be a lot of wasted time compared to just me doing the rebase/typo fix.
• multiple developers working together on a complex patch which touches different parts of the system. This is typical enough in open-source software that the Co-Authored-By commit footer got invented, and would probably happen more at the WMF if support for it in Gerrit would not be so horrible.