Our instance uses a ton of projects as "groups of people that need to be notified", so we use project subscribers a lot.

However, there is an argument that the autocomplete should only list projects with at least one member, since projects without members aren't really useful as subscribers. That might be a middle ground approach that is broadly acceptable.

We use Projects for grouping users into teams. But unfortunately every user can see all Projects and assign them as subscribers to Tasks, regardless if they are members or not. Normally (in our case) Tasks are only relevant for users in the same project. Having the other projects displayed in the subscribers selection is unfortunate in this case.

Of course i see the benefits of projects been used as Subscribers. But i believe in more complex environments the "every user can see all projects" philosophy might be questionable.

Proposal: Add a flag for "visibility restricted to members of project"

Any hint for an alternative way to get this done is appreciated.

@rraval i am not sure how we would handle our situation with that middle ground approach. We have been advised to use Projects for defining user groups. Our user groups are largely independent from each other and of course all our projects contain members. Showing only projects with assigned members would not make any difference for our case...

@Higgs You should be able to Project → Edit Details → Visible To → Project Members. Does that do what you expect?

@rraval Right, i overlooked this setting. I managed to hide most projects from the Subscribers Search panel. We also have reduced the number of Projects to keep things more tidy.

There is one remaining issue left:

I have set all projects to be visible only by administrators. nevertheless a user always can see the projects where they are members, it seems because of this the current project is always listed in the Subscribers Search panel. Although this conflicts with the setting "only visible by Administrators"

I tried to convince the bosses that this may be a good thing, but they pointed out that only "power users" should be able to effortlessly add the project as subscriber, while normal team members should only be allowed to subscribe normal team members. Consequently they asked me to remove the Project from the Search list even if the user is member of the project (which i refused for technical reasons :)

But still it is worrisome that we can configure visibility only by Administrators, yet everybody can assign the project as subscriber... Maybe that is a bug ?

But still it is worrisome that we can configure visibility only by Administrators, yet everybody can assign the project as subscriber... Maybe that is a bug ?

Sorry, I'm not actually familiar with how the permissioning and scoping rules are implemented in code, so I can't comment on what behaviour is right.

However, we've made some progress on this task so I would suggest closing this out and filing a more specific task outlining your scenario so that the powers-that-be can determine if its a bug or not.

(Regarding the original task description:)

It's not configurable, because "we hate config options".

You should be able to hack it locally by replacing the "Datasource" of the relevant field (I think it might be PhabricatorSubscribersEditField - global, not Maniphest only), or by editing the datasource it's using (PhabricatorMetaMTAMailableDatasource).

A workaround is to use the comment textbox to add subscribers by simply mentioning them: type @ start typing, an auto-complete box will pop up that only has actual users, and mentioning a user subscribes them to the object (unless they explicitly unsubscribed before). Use # to mention a project.

As an upstream feature, I don't think that this kind of config is valuable, but some smarter behavior of the autocomplete might make sense - something like:

• Sort recently/commonly used values higher up, or
• Sort projects the current user is member of higher up, or
• Hiding (or sorting low) projects with no members

...a user always can see the projects where they are members...

That's intended, along with some other special-cases permissions for projects (I think a user can also always leave a project?).

But still it is worrisome that we can configure visibility only by Administrators, yet everybody can assign the project as subscriber... Maybe that is a bug ?

That's not expected; Projects you're not allowed to see should not show up in any search feature (including the autocomplete). It might be possible to mention a project you can't see using it's #slug if you already know it.

... in more complex environments the "every user can see all projects" philosophy might be questionable.

The tool that's intended to completely hide stuff from different parts of the install is called Spaces, and to be honest, I'm not sure how it actually works. It lets you put objects and users into spaces, and define stricter visibility rules between spaces.

@avivey Thanks a lot for the hints. I will take a look at the Spaces. That sounds like it could be helpful for our purposes.
@rraval Could you or someone else verify that a project that is made visible only to Administrators still shows up when a user opens the search selection list on the Subscribers field? And is this considered to be a bug or a feature? Of course i can set up a new Task for this if that makes sense.

Nevertheless thanks for your valuable explanations. This already helped us to get much closer to roll out.

@rraval Could you or someone else verify that a project that is made visible only to Administrators still shows up when a user opens the search selection list on the Subscribers field? And is this considered to be a bug or a feature? Of course i can set up a new Task for this if that makes sense.

If a Project is visible only to Administrators, only an administrator can find it, and so, only Administrators can set it in a field like "Subscribers" of something. People who are not Administrators just cannot find it. If one of your users is able to find that, your user is meeting the visibility criteria of that Project. Take a closer look since this feature is very stable and well-tested. I've also tested it in my local installation right now and it works as expected.

BTW I found the Spaces feature very useful. I think it will be very useful also to you, reading you case.

Thank you for all the questions. If you fixed, feel free to mark as resolved.

@valerio.bozzolan Thanks for the feedback and sorry for the late response. I must admit that i forgot how we eventually fixed our issue, i only recall it was more about "avoid the issue" and less about "fix the issue". I also completely forgot about this Maniphest. Hence, it is OK for me that it is closed by now. sorry for not taking care about this earlier.