Page MenuHomePhorge

Subpress listing of Projects in subscriber search
Open, Needs TriagePublic

Description

Hello;

Whenever i add a subscriber to a task by using the search box, i see Project entries and User entries.

I found no way to configure Phorge such that a user (not admin) can only see User entries in the Subscribers search list.

If that is not configurable, can someone hint me where to step into the Phorge kernel to program that specific request ?

Related Objects

Mentioned In
2022-08-23

Event Timeline

avivey removed a subscriber: avivey.

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 ProjectEdit DetailsVisible ToProject Members. Does that do what you expect?

image.png (345×408 px, 26 KB)

@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.