I can't reproduce this either: I've created a new dm namespace, with no users, and navigated to / - that sent me to /auth/register/, no redirect loop.

I'm not sure that will work here; I'm running Apache 2.2.

Also "Fishing Expedition"? That's a bit ... insulting. More than a bit, actually.

I'm not sure that will work here; I'm running Apache 2.2. Older, sure, but completely capable of handling redirects correctly. If Apache 2.2 is too old, that needs to be listed as a system dependency up front.

Got the same problem with only one of my repos (~ 50MB, largest one).
Reverting the commit mentioned by @dtf fixed the problem.

We mitigated with:

In general this falls under "feedback" or "design feedback" (see T10208). We don't have any decent mechanic for taking and holding these opinions in Phabricator. For "design feedback" we currently limit it to what is on the current Roadmap. This helps our small team (2 people) remain focused on building and thinking about the current product.

I'm going to merge this over this since it's not a bug report nor a valid feature request (since a per user option already exists).

Thanks !

(if it helps, this is my virtual host config).

How can I reproduce what you've done to get the same error?

I followed your guide. I ran the ubuntu installation script, followed the instructions for setting up the db, but even before then, the web app was redirect-looping with just those three RewriteRules in place. The REDIRECT_STATUS hack was the only thing that seemed to fix the initial looping but it's not catching the /auth/register loop.

Actually on a real phone it's fine. I guess just something else is causing it at small breakpoints.

I'm not able to reproduce any issues installing Phabricator. Can you provide reproduction steps, specifically?

(Also I assigned this some quest points, but I guess those don't generate transactions yet).

Agreed with @activars - if we can get phab to allow just iframe embedding from google docs, this will be very useful.

On a fresh installation

The rest of this will roll up into other tasks which actually use it, etc.

Will do

In cases where we can find the root cause and provide guidance or raise a setup issue, we do. If you do get more information on this, let us know.

Yeah, I'm planning to let you label the field with whatever you want, I just haven't figured out where I'm going to stick that. Current leading contender is adding some special stuff to maniphest.custom-field-definitions, but I don't love that for various reasons. I may just do some new maniphest.points sort of thing and put some UI on it.

Oh, also in the mock, I had let people set the "noun" for whatever their points were. Which could then be surfaced wherever.

Yeah, fractional points are OK if you're literally labeling the field "Estimated Hours".

points/currency/time are the main things I think people would try to track in a point field

well maybe I'll allow fractional points

Here's my current plan:

Cool, sounds good. There's definitely room for improvement here and we're open to making changes if it turns out you do actually have a few competing use cases to balance, but I suspect you can make reasonable headway on at least some of this by revisiting Config with an eye to dialing settings back toward optimizing the "ignore / review" decision.

@epriestley Thanks! Sorry about our screw-up with the settings. Looks like we had an internal communication problem. I'll follow up and make sure we're exhausting what settings we have available to us (starting with default options) and return to this and the tickets you linked after that.

I don't have any ideas on how to troubleshoot this, since it's most likely to be between the webserver and your browser and I've never run into it personally.

This probably still isn't perfect, but:

Using PHIDs instead of slugs is likely a workaround, but possibly not helpful depending on what you're doing. D15214 should fix the root issue. Thanks for the report!

Never mind, here's an example:

Can you give me an example of a URL which hits this?

No cloudflare or caching.
Did restart the server after upgrade.
Issue began to happen following upgrade + restart on Saturday 30th January.

This generally points to something environmental on your install. Did you restart the webserver / apache after upgrading? Any proxies or other resource caching going on like cloudflare?

Can't reproduce on this install, though.

Ok, checking Firefox's error console and I get
Error: JX.initBehavior(map): behavior(s) not registered: dashboard-query-panel-select
Expanded to reveal:

JX.$E()                                              core.pkg.js:2
JX.initBehaviors()                                   core.pkg.js:178
.members._handleResponse/when_complete<()            core.pkg.js:235
.statics._complete()                                 core.pkg.js:193
.statics._loadJS/load_callback()                     core.pkg.js:184

Yeah, it feels a bit like the "baby's first typeahead" button to me (since it didn't exist for so long, and is usually useless if you know what you're going to select) and it usually takes me a minute to remember it's there.

FWIW I don't think I had clicked on since first testing out typeahead and had come to associate it with "this is a magic typeahead box" not "click for more options".