I don't follow what you're asking for here, what's a subscribers object policy?

The "Subscribers" object policy is PhabricatorSubscriptionsSubscribersPolicyRule, which adds this thing:

A "Project Members" object policy would be equivalent to selecting "Members of X", but easier to pick out of the list and selectable as a default. It's likely fairly straightforward to implement. I think this is broadly reasonable.

A similar policy elsewhere is the Conpherence "Room Participants" object policy:

@chad - that's some object-specific policy... like "subscribers of this project" [is this "watchers" ?]... which to me is weird because I still don't get the distinction between subscribers and members... I mean obviously members are member and subscribers subscribe to changes in project and are not members, but to me subscribers are useless for most projects but members are ;)

So - from my (and possibly @joshuaspence) point of view it would be cool to have another object policy - "members", meaning "members of current project". This would be nice especially for policies like "visible to" and "editable by"... and possibly "joinable by" 😉

It would be even better for other items to have members policy... For example: Differential repos CAN have "project" connected to it. Now it would be freakin' sweet to simply have pre-defined settings for can view/edit/push set to members of associated projects 😄

@epriestley sure types faaast or I'm slow responder... it took me close to 15mins to type above...

haha, never noticed it!

They're fairly recent (last couple of months).

I will go find some now.

@epriestley - can those be set as default policies for objects that can have dynamic policies? For now my default policy is "All Users" and I lock down almost everything to specific projects, but it would be better for me to have project members be deault policy for almost everything.

Yes, but "Project Members" is not the same as "Members of associated projects", and I think we are unlikely to implement that in the upstream. You can implement it as an extension if you want that behavior.

Ou... so "project members" would be rather straightforward, but I guess "members of associated projects" would be NP-hard?

It's not difficult to implement.

I think it's difficult to communicate and understand, and is likely to create a lot of user confusion. I don't plan to bring it to the upstream because I believe it will be too hard for users to figure out and create high, ongoing support costs forever.

For example, it means that tagging a task with a categorical project like Badge Awarded opens it up to a lot of users, and this probably isn't obvious. Effectively, you can no longer use projects to categorize objects if they also affect policies. Similarly, tagging a task with a project like Security wouldn't lock it down, and this also probably isn't obvious. Generally, I think projects and policies are often conveying very different information.

Our expectation is that Spaces can solve most of the problems that "Members of associated projects" would otherwise solve.

FWIW we are using projects this way i.e. setting Editable By to the project itself. The reason is two-fold:

• to prevent non-members to edit the project details
• to prevent random people from moving stuff in the workboards by mistake

The exception is for projects we use for access control only i.e. grouping people but no tasks, in which case they are editable by admins only.

Seems to work completely fine so far.

Thank You, this was perfect reasoning. I'll then consider extension route for
"members of associated projects" and I hope I can get it done ;)

Hello,

I trying to implement this because we need this on our company installation.
Have almost working code now, but can't get thru one problem.

If i set default project policy view/edit to Members and Join to None can't create projects,
because user can't edit until is a member.
If i move join (TYPE_EDGE) transaction (in PhabricatorProjectEditDetailsController) to first $xactions array element transaction failed with "Can't join"
because no one but members can't join :(

Only solution I found is to explicit attach creator of project as project member before $editor->applyTransaction

if($is_new) {
  $project->atachMemberPHIDs(array($viewer->getPHID()));
}

I don't like this solution, but can't find other.
Any ideas?

I will gladly contribute this implementation.