who can help me?

This has promoted to stable and doesn't seem like a contentious change so I don't currently anticipate any need to keep this open or revisit it.

Personal Herald rules do not run for disabled users, so disabling a user will disable all of their personal rules.

Thank you for exhaustive description. One more question:

Primarily, global rules bypass access control policies. They can also apply different actions.

Great and very helpful change, thank you!

Note that it is possible to set a path to the websocket for every server as well. This is handy, for example, when your notification websocket is hosted behind the same URL as Phabricator itself. We have https://phabricator.ourcompany.net/ for Phabricator itself, and https://phabricator.ourcompany.net/ws/ for the notifictions websocket. This corresponds to the following client config:

There don't appear to be any major outstanding issues here.

Thank you very much !

To edit project tags for a repository, navigate to the repository main page, then click Manage Repository → Edit Basic Information and add project tags to the "Tags" field.

Good time of day palls.
How to add tag (respectively connect repo to project) in that new style ?
I'm asking because till now all our commits to HG repo was referenced to task with keywords like "ref" or "closes" etc.
All our repos is organized and setup like that. Today I must create new repo attached to new project and the problem....
Can't reference or act to any task/project with commits?
Or I miss something but can't find even add tag command.
Please advice, thanks in advance !

Thank you for the update, I didn't think of using Conference. I haven't found anything that directed me to /status, just had the url as part of our validation after an upgrade, and went to use it.

There's a new status panel in Config → Notification Servers. I'm consolidating cluster status information there.

Following the upgrade, is there a way to send test notifications and /notification/status/ is now a 404 error?

It should be fixed in HEAD, it just only regenerates once every 24 hours or something I think.

https://secure.phabricator.com/book/phabricator/article/notifications/ needs to be modified to fit the new world.

Here's how I modified the configuration on this host (secure.phabricator.com) to account for this change.

This has been live for some time without any apparent issues.

@epriestley, first time I tried I just wasn't lucky enough to navigate to Config->Versions.
By the way I updated my Phabricator version and it works fine.

@jlvillapalos, can you shed some light on why you didn't include that information in the first place or how we could improve the process?

This is the version information, but it will be very useful to give instructions of where to look to get it.

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

@rdfree50 see https://secure.phabricator.com/book/phabricator/article/support/ for what free support services are available for Phabricator. If you need direct 1 on 1 support from Phacility, we're happy to offer that as well (see https://secure.phabricator.com/w/consulting/).

Hi Evan,

Cool, glad to here its working and thanks for the confirmation.

I was using .htaccess (I noticed the linked article said to remove the leading '/'. I finally got things working. I had to move my rewrite rules to the .conf found in /Library/Server/Web/Config/sites/mysite.conf. This is specific to macs running the OS X Server application. Hopefully if anyone else is using this setup, they can benefit from this.

Are you writing the Phabricator RewriteRule in .htaccess or httpd.conf (or similar)

Lots of interesting details on mod_rewrite here: http://stackoverflow.com/questions/286004/hidden-features-of-mod-rewrite

So I've determined it is a conflict between my .htaccess rewrite rules and some other apache/server configuration. I'm not exactly sure what's happening, but here is an update on the behavior.

T10301 and T9469 are related issues, but neither had any resolution. Would love to know what causes this on the Apache side, if we can improve documentation, etc.

You can also just replace index.php in webroot with <?php var_dump($_REQUEST); ?> to rule out any hanky-panky from Phabricator.

Maybe give it a spin in Charles? https://www.charlesproxy.com/

That's how I originally had it configured, but now I'm using OS X Server. When installed it stops using the default /etc/apache2 configuration and instead uses /Library/Server/Web/Config/. I have a few other websites configured on my home vpn which are accessible via site1.mydomain.ddns.net and site2.mydomain.ddns.net. I have the phabricator alias record configured the same way.

I run dev on a local OS X machine, basically I just manually set a DNS inside with /etc/hosts in my house (dev.macbook.local) on each machine I want to access it on. I'm curious if its a ddns issue.

I'm still not sure, but I cannot verify like I thought before it was related to the rewrite rules. My setup is on a device running OS X Server. I have the phabricator installation at phabricator.mydomain.ddns.net, but I am still continuing to see the "Request exceeded the limit of 10 internal redirects due to probable configuration error."

In T10352#159245, @ianvkoeppe wrote:

This task can be closed.

This task can be closed.

Hi Evan,

Technically, this is "Invalid" as steps to reproduce the issue outside of the user's environment have not been provided, see Contributing Bug Reports for more information for what we take as a valid bug report. If a reproducible steps are provided and verified, we're happy to re-open and fix any issue in Phabricator or in the Documentation.

It looks like the reporter has moved on for other reasons:

One final idea: Let's just take Phabricator completely out of the equation, assuming you followed our installation guide.

@bob.apthorpe Poor sense of humour on our part aside, what else can we do to help you here? Do you have more specifics on reproducing the bug you can share with us? Unfortunately no one is able to reproduce with the steps you've provided and we have no other reports of issues with installation (T9469 was also a http configuration issue). Your twitter posts seem to indicate this server may not be directly under your control? Can you test in another environment or VM?

The fact that you had to add RewriteCond %{ENV:REDIRECT_STATUS} ^$ implies some redirect loop inside the apache, before phabricator shows up?

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.

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

This has been live for a few weeks without any issues, and I generally expect it to have nearly zero impact on reasonable workflows, so I'm going to assume the best and close this out.

The WMF-specific aspects of this are covered on the WMF install in https://phabricator.wikimedia.org/T125104, and that looks like it has a promising path forward that doesn't rely on this event. We haven't seen other outstanding unresolved issues and this has been in the wild for about two months now, so I'm going to assume the best and close it out.

This has been live for a couple weeks without making any waves and these changes were all pretty straightforward so I'm going to assume we're in good shape, but yell if anyone bumps into issues.

doesn't seem like good practice

The first hit on Google for "phabricator daemons" should be the documentation for them:

Thanks epriestly for detailing about the error and also the solution to it. Yep that was an database issue. After logging in as admin I was successfully able to update the phabricator.

If you are new to Phabricator or have not modified Maniphest much, this post does not pertain to you.

Hi Evan,

This is probably because the user you are connecting with does not have permission to access the database.

This has been quiet for a while, seems like nothing broke too heavily.