@mark are you ok with us approaching this? Previously you wanted to be more comfortable with Phab permissions. What do you think?

I suppose the next steps are: add procurement project, add said project to direct email allowance settings, test with drop down

We also need to confirm with @mark that we are fine with all users in the WMF-NDA group viewing procurement.

In T93760#1146244, @RobH wrote:

We also need to confirm with @mark that we are fine with all users in the WMF-NDA group viewing procurement.

That conflicts with this:

Procurement project task has to be locked down by view/read/edit/everything to ONLY Wikimedia employees.
Trusted volunteers/NDA still do not have any reason to access these.

The default access policy should be to be open (to people who already signed NDAs) unless we have $reason why these are different from other private things.

I realize I corrected myself from employee to NDA. It was intentional since we don't have an employee list in phabricator.

Procurement project task has to be locked down by view/read/edit/everything to ONLY Wikimedia employees.
Any email attachments into task should automatically have security settings applied to ONLY be viewable to WMF staff.
Volunteers shouldn't interact with the tasks, so WMF-NDA is required to ensure only the ones who signed an NDA can view. Unfortunately we don't keep a staff list in phab, so NDA is the tightest we can lock it down without managing a new group.

This still doesn't make any sense. Volunteers can and sometimes do sign NDAs with WMF. You will have to create a new group (and maintain it, and give very, very good reasons) to restrict it to staff employees only (not even contractors). You need to address @Dzahn's comment.

I'm not sure what part I have not addressed. We are currently planning to allow WMF-NDA access to the proposed procurement project tasks.

We do NOT want to have to start maintaining a staff group, so it is an acceptable risk to allow NDA volunteers to see quoting. They shoudn't be contacting folks via them, but they know this from use in RT.

I thought my other answer on the 25th addressed this, but perhaps this more detailed comment will suffice.

Change 200787 had a related patch set uploaded (by RobH):
allow direct emails from vendors to procurement

https://gerrit.wikimedia.org/r/200787

Change 200787 merged by RobH:
allow direct emails from vendors to procurement

https://gerrit.wikimedia.org/r/200787

As seen in test task T94507, attachments added via email to an existing task in Phab do not inherit the task's permissions.
See the docs in https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments and https://www.mediawiki.org/wiki/Phabricator/Security stating "There is no way to set policy on a task via email." which could likely be extended to state "on a task or file" to have the docs be more explicit about this?

Is or could be T823: Implement Phabricator Spaces a blocker for this task?

In T93760#1339479, @Qgil wrote:

Is or could be T823: Implement Phabricator Spaces a blocker for this task?

If it fixes "email an attachment into the task & ensure its attachment isn't viewable to anyone not in the NDA group", yes. If it is unrelated to permissions on attachments added via email, no.

The policy of a space should determine the policy of all objects living in that space, files just as much as tasks.

https://secure.phabricator.com/T8376#120180

Per T8498, you can now send mail to test-space-bugs@phabricator.com to create tasks directly in S2 (join Space Test Users first if you can't see it). T8514 is an example.

The comment upstream contains the links. Files in attachments can be accessed by users according to the policy of the space.

So things kept referring to a space I couldn't join. I overrode the options for S2 and added myself into the group view rights, once I had a single task to test loading, i went ahead and left them and couldnt then pull up the task data.

This seems like enough of an initial overview to move ahead and implement a 'vendors' space where we keep any vendor documents or private communications. Access to the space will be restricted to WMF Staff. As there are no volunteers involved within the financial or capex areas of our tasking, there doesn't seem to be any reason to open that particular space further. However, we'll start testing and go from there. The most open the space could be is for WMF Staff and NDA.

In T93760#1580903, @RobH wrote:

Access to the space will be restricted to WMF Staff. As there are no volunteers involved within the financial or capex areas of our tasking, there doesn't seem to be any reason to open that particular space further. However, we'll start testing and go from there. The most open the space could be is for WMF Staff and NDA.

As long as it only includes a small subset of staff (and potentially contractors/NDA volunteers?) who do need to see what's in there, on an individual basis (unless they're in ops?), sounds reasonable.

Nope. There is an ongoing discussion and vendor quotes and communication have to remain staff only for now.

In T93760#1581068, @RobH wrote:

Nope. There is an ongoing discussion and vendor quotes and communication have to remain staff only for now.

That contradicts what you said in your previous comment, but whatever. And it doesn't answer the other question.

It does indeed, I was corrected in private about the policy regarding vendor communications.

So we have to keep them for wmf employees only at this time.

In T93760#1580903, @RobH wrote:

So things kept referring to a space I couldn't join.

Are "things" the quotes above in this task?

I overrode the options for S2 and added myself into the group view rights

The reference above to S2 was a direct quote from upstream upstream and hence refered to upstream's S2 Space. In the meantime in Wikimedia production Phabricator, an S2 Space had been created used by the CL team. I see that you already reverted your changes in the production system - thanks.

General documentation can be found in https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Restricting_access_via_Space_policies

@Aklapper: Indeed, I misunderstood which were testing spaces and which were not. I thought S2 was a privacy testing space, not an actual team working space. So once I joined it (via using my opsen admin powers) and saw it wasn't a general private testing space, but a team's space, I reverted all my access from it. (Sorry about that!)

Since then I've created S4 and set it to view/edit by admins and SRE.

The plan is to add other viewable by users on a one by one basis, as I've been instructed that we need to keep access to vendor communication restricted to WMF staff only at this time.

So I misunderstood Krenair but IRC chat cleared it up.

The general concern is any space that is open to all staff by default may quickly devolve into a backchannel ticketing space for things that have nothing to do with vendor communication or pricing. This can be offset by ensuring that S4 remains only accessible by those directly involved in vendor communication and pricing.

SRE is presently ONLY members of ops (plus ori, we like ori). When I need individuals to review specific quotes, I'll add them into the allow view of the space. (This means when we offboard, we need to include phabricator projects/spaces like this in the review.)

My understanding of @Krenair's issue is I am using SRE project which says it uses the ops group (which can include volunteers) for access to a space that is for the ops group (employees only).

That the overall member list of SRE happens to not includes anyone but staff is simply a coincidence at this point in time, and therefore has the real potential to quickly become invalid for access when users are added to it following its suggested criteria on the info page of SRE.

As such, I've appended the testing note not to add volunteers to that project for now (which would only include @RyanLane or @Domas at this time.)

So I thought of what I think is a better solution.

procurement is the project for vendor quotes, S4 is the space. procurement is already a closed membership, and I add in users on a case-by-case, user-by-user basis.

S4 has been changed to filter based off that group, not SRE. This ceases the use of SRE for access based on the reasons outlined earlier in task. (Basically the group's scope is too large for that use, as it can include many volunteers that may not otherwise require access to S4.)

I've probably missed some discussion -- can someone explain why we need a separate "space" for this?

@faidon: spaces are the best way to ensure complete privacy of the task. It is outlined in the task above (plus a lot of out of band discussion).

My understanding is the best way to ensure this content stays private is to place the procurement tasks into the private space. The issue is the email bot attachment was coded before spaces, so it has to be updated to work with them.

That being stated, perhaps @Aklapper or @chasemp can give a better reasoning, as they both recommended spaces and understand the reasoning behind it.

A space ensures that even if you accidentally (or deliberately) open an object's policy to something that shouldn't actually be able to view the contents, it's still restricted to being viewed only by people who can view the space. It does mean you don't have to fiddle with ad-hoc visibility policies for every new private task, or use our security dropdown hack (for unprivileged users - direct task policy manipulation is a restricted, privileged action) to create private tasks.

Really I wish they'd built a sort of policy template system instead of spaces - so that you could administer policies centrally (e.g. grant or remove a user's access to all objects with a given policy template) as well as restrict who can set up ad-hoc ones, while still allowing you to whitelist individual people for individual objects without having to give them access to the whole space.

So the new S4 space testing so far is working out, except for a few things.

• I hate having any kind access based on #projects rather than #acl*project/teamname. As such, I'll be assisting on T90491 to create the acl*operationsteam group (which resolves the entire SRE following project issue mentioned on T90491) and then can also be used to control access to S4.

S4 Vendor pricing space will be for WMF staff only, and I am not about to try to maintain a full staff list. As such, we'll instead allow the ops team (which we can control and maintain that acl within the ops team) and then users on a case-by-case basis. Once I start adding users to the acl*procurement (which will include ops team), part of our ops offboarding review will be removal from associated controlled spaces (like s4 and its acl groups)

As all the ACL groups have been completed, the next step is to simply start testing regular use. (We've done our initial task creation and attachment tests, as well as emailing in to said tasks.)

The first items pushed into this will likely be items where the pricing is already public, just in case we have any issues. (So transceiver orders, power cables, online ordered items with no discounting.)

Great news! I'm very happy to see that our investment in Spaces keeps paying off.

So... does this mean that RT is now completely migrated, and not in active use anymore?

In T93760#1795810, @Qgil wrote:

So... does this mean that RT is now completely migrated, and not in active use anymore?

Nope, see T118176: migrate RT maint-announce into phabricator