Page MenuHomePhabricator

Moving procurement from RT to Phabricator
Closed, ResolvedPublic

Description

Moving our procurement process into phabricator requires a few things. This task will outline the proposed workflow for a procurement task, and the relevant security settings.

Workflow:

  • User creates a hardware-requests task for the hardware.
  • If hardware needs to be ordered, Rob creates a procurement task in the S4 Vendor Quote space for each quote/vendor combination.
    • Example: We need a new database system on task A (hardware-request). Then we create Task B in the S4 procurement for Dell quote, and Task C in the S4 procurement for HP quote.
  • Rob deals with Dell on Task B, they email back with quotes and options.
  • Rob deals with HP on Task C, they email back with quotes and options.
  • Ops determines which specification/quote to go with, and escalation of the task begins for approvals.
  • Task for approval has to be viewed by Mark, and upper management for approval. Mark tends to comment on task, where upper management will likely email their approval back into task or to Mark (who then forwards it into the task.)
  • Once order is placed, the S4 procurement task is assigned to the on-site tech to scan the packing slip.
  • On-site receives in order, and resolves the task with relevant details and resolves. If there are issues, onsite notes issues and assigns back to Rob.
  • S4 procurement task has to be able to directly email to task T###@phabricator.wikimedia.org
  • S4 procurement has to be locked down by view/read/edit/everything to ONLY WMF staff
    • We don't want to maintain a full staff list, so we'll include the ops team by default and then add others on a case by case basis.
  • Any email attachments into task should automatically have security settings applied to ONLY be viewable to those who can view the task.
    • This is confirmed now working, as @chasemp updated our emailbot importing to have attachments owned by emailbot, and only viewable via the task they were imported from.
  • ALL procurement tasks should be placed into the S4 space, as they may include confidential pricing.

Task creation steps & tests :

  • - generate a new S4 procurement task & ensure its creation doesn't leak private info.
  • T110566 was created in the S4 space without issue.
  • - email an attachment into the task & ensure its attachment isn't viewable to anyone not in the NDA group.
  • After @chasemp's work on emailbot, T110566 now has emailbot imported files that are confirmed only visible via the task linking. (Direct linking fails.)
  • - test if someone not a memer of the acl*procurement group can be assigned to S4 procurement tasks.
  • Cannot test until after we create the acl*operationsteam and acl*procurement groups.

Related Objects

StatusAssignedTask
ResolvedQgil
ResolvedQgil
ResolvedQgil
Resolved RobLa-WMF
ResolvedQgil
ResolvedDzahn
ResolvedQgil
ResolvedAklapper
Invalidmmodell
Resolvedmmodell
Resolvedmmodell
DeclinedQgil
Declinedgreg
ResolvedRobH
ResolvedRobH
ResolvedQgil
ResolvedRobH
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
DeclinedAklapper
ResolvedQgil
Resolvedchasemp
Resolvedchasemp
Resolvedchasemp
Resolvedchasemp
Resolvedchasemp
Resolvedchasemp
ResolvedQgil
Resolvedgpaumier
ResolvedAklapper
ResolvedDzahn
ResolvedDzahn
DeclinedNone
ResolvedRobH
DuplicateRobH
Declinedmmodell
Duplicatemmodell
ResolvedQgil
Resolvedmmodell
ResolvedSpringle
ResolvedNone
Resolvedmmodell
ResolvedRobH

Event Timeline

RobH created this task.Mar 24 2015, 3:55 PM
RobH updated the task description. (Show Details)
RobH raised the priority of this task from to Needs Triage.
RobH added a project: acl*sre-team.
RobH added a subscriber: RobH.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 24 2015, 3:55 PM
RobH claimed this task.Mar 24 2015, 3:56 PM
RobH added a subscriber: chasemp.
RobH updated the task description. (Show Details)Mar 24 2015, 6:47 PM
RobH set Security to None.
RobH renamed this task from detail blockers for procurement in phabricator to Moving procurement from RT to Phabricator.
RobH triaged this task as High priority.
RobH reassigned this task from RobH to chasemp.Mar 24 2015, 6:48 PM

@chasemp: I think the above details what I need for procurement in phabricator. Please review and provide feedback.

chasemp added a subscriber: mark.Mar 24 2015, 7:08 PM

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

RobH added a comment.Mar 24 2015, 7:19 PM

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

RobH added a comment.Mar 24 2015, 7:20 PM

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

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.

Dzahn added a subscriber: Dzahn.Mar 24 2015, 8:02 PM

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.

Aklapper changed the status of subtask T93796: create procurement project from Open to Stalled.Mar 25 2015, 1:31 PM
RobH added a comment.Mar 25 2015, 2:40 PM

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

RobH changed the status of subtask T93796: create procurement project from Stalled to Open.Mar 25 2015, 2:41 PM
RobH updated the task description. (Show Details)Mar 25 2015, 2:57 PM
mark changed the status of subtask T93796: create procurement project from Open to Stalled.Mar 25 2015, 2:59 PM
jeremyb changed the status of subtask T93796: create procurement project from Stalled to Open.Mar 25 2015, 3:03 PM
Krenair added a comment.EditedMar 25 2015, 6:15 PM

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.

RobH added a comment.Mar 26 2015, 4:40 PM

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.

RobH claimed this task.Mar 31 2015, 12:07 AM

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

RobH updated the task description. (Show Details)Mar 31 2015, 12:27 AM
RobH added a subtask: Restricted Task.
RobH updated the task description. (Show Details)Mar 31 2015, 2:17 AM
RobH updated the task description. (Show Details)Mar 31 2015, 2:21 AM

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?

Dzahn removed a subscriber: Dzahn.Mar 31 2015, 4:38 PM
Qgil added a subscriber: Qgil.Apr 7 2015, 2:49 PM
RobH lowered the priority of this task from High to Normal.Jun 4 2015, 7:34 PM
Qgil added a comment.Jun 4 2015, 11:06 PM

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

Dzahn added a subscriber: Dzahn.Jun 4 2015, 11:55 PM

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.

Qgil added a comment.Jun 5 2015, 8:30 AM

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

Qgil added a comment.Jun 11 2015, 6:02 PM

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.

Restricted Application added subscribers: Matanya, scfc. · View Herald TranscriptJul 2 2015, 1:58 PM
RobH added a comment.Aug 27 2015, 5:58 PM

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.

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.

RobH added a comment.Aug 27 2015, 6:28 PM

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

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.

RobH added a comment.Aug 27 2015, 6:30 PM

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.

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

RobH added a comment.Aug 27 2015, 6:34 PM

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

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.

RobH added a comment.Aug 27 2015, 6:42 PM

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.

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

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

RobH added a comment.Aug 31 2015, 5:26 PM

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 Operations. This ceases the use of Operations 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.)

faidon added a subscriber: faidon.Aug 31 2015, 5:49 PM

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

RobH added a comment.Aug 31 2015, 9:22 PM

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

RobH added a comment.Aug 31 2015, 10:07 PM

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.

chasemp closed subtask Restricted Task as Invalid.Sep 4 2015, 9:39 PM
RobH added a comment.Sep 16 2015, 10:27 PM

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 Operations 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)

RobH updated the task description. (Show Details)Sep 16 2015, 10:34 PM
RobH added a comment.Oct 21 2015, 7:11 PM

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

RobH closed this task as Resolved.Nov 9 2015, 7:41 PM

I resolved the last RT procurement tickets today, and now we use phabricator for all procurement.

Qgil awarded a token.Nov 10 2015, 2:44 PM
Qgil added a comment.Nov 10 2015, 2:47 PM

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?

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