It's vaguely possible we may implement this eventually, but it's not going to happen any time soon and almost certainly not this year.

Would abovementioned approach be viable? I.e. filtering the list of users in /people/, and those which typeahead and similar functions provide? Would you accept a patch that implements it that way? Do you have any other suggestions on how to implement this efficiently?

This isn't a priority, which means I don't want to spend time planning, reviewing, merging, or supporting it right now, not just developing it.

Writing a patch is only a tiny fraction of the total cost of making a change. When we spend time on something less important, that time is taken away from something more important, regardless of whether I'm planning/reviewing the less-important thing or actually writing the less-important patch. It's still taking up my time working on something less important instead of something more important. See discussion here:

https://secure.phabricator.com/book/phabcontrib/article/contributing_code/

I am now using following patch locally:

See below for the current, complete patch

I added following patch to allow admins to add users into spaces, if currently that user is in no space at all:

See below for the current, complete patch

Otherwise it would be impossible to add these users to a project (and thus space).

You might argue that this just workarounds a configuration speciality on our instance: Users have no access to any space by default. This is because the default space is already restricted to employees only, which gives a lot of control over external users, because they are unable to login until someone explicitly puts them into a space.

I updated the patch yet again. In this iteration, anyone can add users to projects, if these users are not in any space at all.

commit da493478448a19a2f2ae1d9528e0ac89c3fcfcc9
Author: Dennis Schridde <dennis.schridde@uni-heidelberg.de>
Date:   Fri Jul 31 12:10:08 2015 +0200

    Hide users from typeahead boxes which are not in any of the viewer's spaces
    
    These checks are ignored for users, who are not in any space (and thus no common space), to allow people to add them to projects anyway.
    
    Ref: T9021

diff --git a/src/applications/people/typeahead/PhabricatorPeopleDatasource.php b/src/applications/people/typeahead/PhabricatorPeopleDatasource.php
index cdd6898..5ffd703 100644
--- a/src/applications/people/typeahead/PhabricatorPeopleDatasource.php
+++ b/src/applications/people/typeahead/PhabricatorPeopleDatasource.php
@@ -40,6 +40,32 @@ final class PhabricatorPeopleDatasource
 
     $users = $this->executeQuery($query);
 
+    $filtered_users = array();
+    foreach ($users as $user) {
+      $spaces = PhabricatorSpacesNamespaceQuery::getViewerActiveSpaces($user);
+
+      if (empty($spaces)) {
+        $filtered_users[] = $user;
+        continue;
+      }
+
+      foreach ($spaces as $space) {
+        $policy = $space->getPolicy(PhabricatorPolicyCapability::CAN_VIEW);
+
+        try {
+          PhabricatorPolicyFilter::requireCapabilityWithForcedPolicy($viewer, $user, PhabricatorPolicyCapability::CAN_VIEW, $policy);
+        }
+        catch (PhabricatorPolicyException $ex) {
+          continue;
+        }
+
+        $filtered_users[] = $user;
+        break;
+      }
+    }
+
+    $users = $filtered_users;
+
     if ($this->enrichResults && $users) {
       $phids = mpull($users, 'getPHID');
       $handles = id(new PhabricatorHandleQuery())

One issue might be projects and their member list. Users from other spaces should probably be replaced with a "question mark" placeholder, so that others don't know who it is, but see that the project has some members. That way generic cross-space groups don't become a privacy/security issue.

@devurandom - I am facing a similar problem in my installation regarding "corporate secrets". How to I get this and perhaps other similar patches up and running?

@PicoCreator:

1. Paste the patch into a $FILE
2. cd $PHABRICATOR_SRC
3. patch -p1 < $FILE