In this case, we have a new developer and he needs to be added to multiple projects.

In this case, we have a new developer and he needs to be added to multiple projects.

I'm going to ask you a series of questions to figure out what your actual root problem is. When we're done, I'd like you to explain why you didn't just describe it in the first place after reading Describing Root Problems, and how we could improve that document so that you would have gone through this process on your own, umprompted, without requiring me to spend time asking you questions instead of improving Phabricator.

The request doesn't state a core problem, which is required on all feature requests. A core problem is the why of the feature request. See Describing Root Problems if you need a bit more help understanding what we're looking for. We already have thousands of other feature requests, so if you tell us what you're trying to do and why, there may already be another task or another means to accomplish what you want.

In fact, I did read it. I believe I've effectively described the problem. I can't believe that nobody else has this problem nor that the intent of my feature request is unintelligible. Would a more compliant description be: There is no way to add a user to more than one project at a time. Visiting each of 30 projects individually is a waste of time. Or even, more generally, modifying a user's settings for global things like project membership is impossible without visiting each project individually.

You've read that documentation and this request represents a sincere effort to follow the instructions it contains?

I guess I'll never know what I did wrong. Thanks for your time.

Please see Contributing Feature Requests for help submitting a feature request. Thanks!

In PhabricatorApplicationDatasource, do a PhabricatorApplication::isClassInstalledForViewer(...) test on each application and skip it if it is not installed. You can get the class name with get_class($application_object).

Turned out the fix above:

prepped.body = prepped.body + '&projectPHIDs=%5B%22' + projectPHID + '%22%5D'

does not really work. What works is this:

import requests

I was looking for similar functionality (publish the state of some external system on a panel) and instead of updating the entire panel I think it would be nice to use Phlux or Paste:

I think there's another one of these in DivinerAtomController->composeTasks(). The other getDocblockMetaValue() calls anywhere in the codebase are also suspicious.

Oh man -- I didn't notice that the random test account I was logged in as in Chrome (named wwwuuu) was an administrator. I have a repro.

Part of this is likely a change to the semantics of setTimeout(). Current uses are:

@epriestley : Alright then, Thanks.

Sounds good. Let me know how I can help

Alright, thanks. I'll look at this in more detail.

You can manually edit conf/local/local.json instead of using bin/config set.

@epriestley : Ouch! - Alternatively since all of you are already on it. What git commit can i revert to quickly fix this? (Note it was a clean clone i am trying to re-setup)

Nope, that doesn't work either..

Sniped!

Does this work?

The 24-hour data in multimeter shows a drop from about 1.1M requests per day to about 41,000, so that's a slightly-better-than-95% reduction in request volume. The worst sample we caught in the last 24 hours for api.almanac.service.search was 228ms, and the median was closer to 70ms.

This is somewhat involved to untangle because the old logic was actually wrong and had a small chance of executing a page incorrectly.

Opened T11593: *.search Conduit API methods with invalid constraints silently ignore the constraints for this.

Ill go true Contributing Feature Requests and submit it properly.
This is a must feature, even gmail add it today with blue dot! (maybe its partial release)

Ah, okay, that's actually consistent with what I'm seeing -- I think I repro'd the web version. You do sometimes need to restart the web thing to get this flow to work fully (we run some special, more-helpful checks during setup, which is only run after restart), but I believe it doesn't matter in this case since the setup checks are a little buggy.

maybe I need to restart?

It does work from CLI, not from web.

Specifically, we only take feature requests as problems, that is, that you have an issue you're not able to solve currently in Phabricator. This idea is nice, but problematic when combined with all the possible applications we have (in particular our chat client Conpherence). If we do anything with the favicon, it'd likely be for direct mentions.

let me try again since I've gotten sleep. 8)

@chad, I'm having trouble reproducing the patch from P2007 not working. Here's what I did:

This doesn't appear to be a valid feature request. See Contributing Feature Requests.

@epriestley You (and your team) are freaking epic. I owe you a beer (or several). If you're ever near Basingstoke, UK drop me a line!

I don't think we should actually trim() the address -- if you have bad data in LDAP, you should fix it.

This should now be fixed in HEAD of master. I've also cherry-picked it to stable.

Even though I think there's a good technical argument that our behavior is reasonable, the lifetime support cost of changing the application logic to be more similar to what browsers do is almost probably lower than the lifetime support cost of documenting this explicit port behavior, since there will be 100 more people who try the same thing in the future and maybe 5 of them will read the docs if we're lucky.

Adjusting the redirect to use `phabricator.pt.local:80' also fixes the issue, though I have removed it as I don't think anyone here still tries to use an IP...

Confirmed, removing that redirect at the top of my apache config. also resolves the problem without changing the upstream.

This is probably the issue:

I had to look that up its been so long since I fiddled with the server hosting.

Prior to that change, we did not send ports in Host: headers in requests.

Spot on! reverting that change on my arcanist client resolved any issues completely.

If you revert rPHU491ebc74d816dbe2fc8bbbbc992e8a14f8c613be in libphutil, does that fix it?

I can replicate the cURL error from a configured repository, its the same trace as that of the arc which command above:

[2016-09-05 10:06:49] EXCEPTION: (HTTPFutureCURLResponseStatus) [cURL/47] (http://phabricator.pt.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS at [<phutil>/src/future/http/HTTPSFuture.php:408]
arcanist(head=stable, ref.master=9e82ef979e81, ref.stable=10e519475290), phutil(head=stable, ref.master=c8b76485ef84, ref.stable=f748cdbc8d08)
  #0 HTTPSFuture::isReady() called at [<phutil>/src/future/Future.php:37]
  #1 Future::resolve(NULL) called at [<phutil>/src/future/FutureProxy.php:34]
  #2 FutureProxy::resolve() called at [<phutil>/src/conduit/ConduitClient.php:64]
  #3 ConduitClient::callMethodSynchronous(string, array) called at [<arcanist>/src/workflow/ArcanistWorkflow.php:332]
  #4 ArcanistWorkflow::authenticateConduit() called at [<arcanist>/scripts/arcanist.php:356]

Interesting:

echo '{}' | arc --trace call-conduit --conduit-uri http://phabricator.local/ --conduit-token cli-37au4odrzomsk54zbnolivacknw3 user.whoami
 ARGV  '/home/sam/bin/phabricator-tools/arcanist/bin/../scripts/arcanist.php' '--trace' 'call-conduit' '--conduit-uri' 'http://phabricator.local/' '--conduit-token' 'cli-37au4odrzomsk54zbnolivacknw3' 'user.whoami'
 LOAD  Loaded "phutil" from "/home/sam/bin/phabricator-tools/libphutil/src".
 LOAD  Loaded "arcanist" from "/home/sam/bin/phabricator-tools/arcanist/src".
Config: Reading user configuration file "/home/sam/.arcrc"...
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/home/sam/Coding/UMC/Src/.arcconfig".
Working Copy: Path "/home/sam/Coding/UMC/Src" is part of `git` working copy "/home/sam/Coding/UMC/Src".
Working Copy: Project root is at "/home/sam/Coding/UMC/Src".
Config: Did not find local configuration at "/home/sam/Coding/UMC/Src/.git/arc/config".
>>> [0] <conduit> user.whoami() <bytes = 117>
>>> [1] <http> http://phabricator.local/api/user.whoami
<<< [1] <http> 195,683 us
<<< [0] <conduit> 195,955 us

What do you get if you run the same command with --trace flag ?

Further testing, the standard curl request seems to be fine:

curl http://phabricator.local/api/user.whoami \
>     -d api.token=cli-37au4odrzomsk54zbnolivacknw3
{"result":{"phid":"PHID-USER-omtmnetw55dqsgt576g7","userName":"Sam","realName":"Sam","image":"http:\/\/phabricator.local\/file\/data\/g57z5iku5s2x4rpi7k6r\/PHID-FILE-xhdrpuvh5lbu7tmkfso5\/profile","uri":"http:\/\/phabricator.local\/p\/Sam\/","roles":["admin","verified","approved","activated"],"primaryEmail":"Sam@blahblah.com"},"error_code":null,"error_info":null}

It also works from the web-conduit application in phabricator http://phabricator.local/api/user.whoami, but it fails from arc:

echo '{}' | arc call-conduit --conduit-uri http://phabricator.local/ --conduit-token cli-37au4odrzomsk54zbnolivacknw3 user.whoami
Exception
[cURL/47] (http://phabricator.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS
(Run with `--trace` for a full exception trace.)

Weird.

How about subpages? It would be really useful to be able to print out / export an entire hierarchy with one click.

Maybe it is ok for the import from LDAP module to trim leading and ending spaces.

To correct my previous post.
The real cause of the error is Email addresses should be in the form 'user@domain.com'.

New Info.

Hmm, yeah I wonder if it's anything we can detect on our end. Doesn't sound very common though.

I just tried again. It seems that I miss the latter part of the error message.

Do these fail for you during single person invites as well or only during LDAP?

These are valid email addresses in Phabricator. I don't have any other ideas why you're running to an error.