What specific bad outcome are you concerned about if Department A can edit Department B's objects? That is, why is it important that these edits be prevented? For your organization, what's the worst case scenario if everything is just editable by "All Users"?

Typically the latter (Department A can see Department B's stuff but not edit).

Do you not want Department A to see any of Department B's stuff?

Thanks for the report! D15274 should make this dialog more user-friendly once it lands.

When I say subscription I mean membership. We use projects as the top-level partition for all different "departments" that use Phabricator. So say Department A has a project B and project C in which the entire department should really be members, they now have to add the members to both project A and project B. Unless I am not understanding this fully. Ultimately we use project membership in permission/membership entries for tasks and other areas (like queries/dashboards) specific to each department.

T10358 discusses a case where we use (valid, spec-compliant) JSON for presentation, but could use an alternate form which is more human readable (specifically, when displaying unicode characters).

@kislinsk In cases like the one you describe (which I consider reasonable), what's your major concern with naming the subproject "ABC (Core)" to resolve the ambiguity of a task tagged with both "ABC > Core" and "XYZ > Core"?

Why do you want to subscribe to all subprojects of a parent project individually? Can you talk about your use case in greater detail?

My .02 fwiw: It would be nice if there could be members of a parent project (which will effectively mean that they are members of all subprojects) so that users don't have to subscribe to each subproject individually. Maybe just as a "default membership" list that copies to each subproject since membership of a parent project is now deemed to be a union of all subprojects...

You are out of date: update Phabricator to resolve this issue.

My thoughts on the subproject UI concerns: We were really looking forward to subprojects especially to simplify organization of software components and their appearance in the UI. For example, we have multiple projects managed by the same Phabricator instance and software projects tend to have the same name for many software components like Core, UI, and so on.

Deleted JS directory.
/daemon/ link shows no failing task recently:

For my (and others') understanding, the discussion is limited to how to make the needed changes BC, otherwise https://github.com/RustJason/xhprof/tree/php7 would be fine? If so, might I suggest a new major version?

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

@avivey Sure, you're right. Thanks!

(Technically, "invalid", because it's not a bug.)

This task can be closed as Resolved.

Delete the JS directory, and visit the /edit page; It should show information about the state of the daemons.
Look also at the daemons console (Navigate to /daemon/), and look for failing daemons and logs.

deamon is running as root user

@avivey @chad Thank you for your attention. Yes, I did - please see below for the happy end :-).

Definitely is a restart issue. That file was removed and you shouldn't have any current code looking for it. Either your pulls were incomplete or your webserver / php wasn't restarted (we cache lots of stuff). See also https://secure.phabricator.com/book/phabricator/article/restarting/

/var/repo/ needs to be owned by the daemon user (The user that phd runs as), and the daemons need to be running.
When importing git/mercurial repos, the daemons copy all the content to /var/repo/CALLSIGN; That doesn't happen with SVN, which is why you didn't run into this before.

Did you restart your webserver, php-fpm, etc?

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.

I'd like to translate Phabricator in French, if the support for translatewiki.net is implemented.

Findbugs produces HTML, so I've made it into remarkup at https://github.com/avivey/remarkup-java (In Community Resources).

For example, here's a possible sequence of events which might be leading to this:

Do you know why users are adding "All Committers" as "Reviewers"? We haven't seen that on this install, but maybe your flow is different somehow?

Oh yeah it's reasonable to find another solution for you.

I agree. This feature is suboptimal from a complexity and product point of view. Personally, I'd love to see much more powerful Herald system than specific features added to solve smaller use cases. I wasn't trying to ask you to implement this feature so much as I was trying to say that the underlying problem is real and ought to be solved.

Overall my concern is that this is the kind of feature that causes more problems than issues it resolves. It makes Phabricator much harder to build, to test, to document. It makes it harder for users to configure and understand, and it causes product confusion to the end user. Pretty much any workaround is going to be preferable, unfortunately.

That would be helpful and solve the entire problem if emails were completed post-transaction (i.e., one didn't get an email for being a reviewer and then another for being removed). I'd love to add a Herald rule that says 'if any of these projects are added, remove them'.

What about having a "Remove Reviewer" Herald Rule?

@epriestley The FreeBSD install is seeing a lot of confusion around this. We have some groups used for policy ("all committers", "all people with access to this repo") which are getting added to reviews. This causes the main dashboard to be useless and likely causes people to filter from phabricator.

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.

Thanks, looks like we updated the links a month ago but missed rolling the server.

I need to finish my social sharing diff for Phame

Hi Evan,

I'm leaning toward this:

Thanks for the suggestion, we'll keep it in mind.

This task now has scripts to migrate points and move projects underneath other projects. Let me know if you run into issues.