Page MenuHomePhabricator

Provide better control over mixing denial of access to users in the default space
Closed, ResolvedPublic


  • We have all of our FTEs in S1. This is driven by membership in an Employee group. This gives access to more or less everything: tasks, repos, etc. More or less everything is configured to be visible to people in this space.
  • We have contractor accounts scattered across a few other highly restrictive spaces.. These typically are project membership driven (i.e. a Contractor group) and only allow you to see objects that have explicitly been created in one of these spaces (mostly tasks for a specific contractor workboard.)

We've now found ourselves in a position where we have some contractors that need expanded, but not full, privileges. We want them to be able to see all tasks and our wiki, but they have no need to access/clone source code. The only way I can think of to do this easily is to add them to a hidden group like #NoRepo and update Diffusion policies. This seems hacky and worse error prone - it requires a step to deny privileges, which is generally a bad idea since it can easily be missed.

An annoyingly-complex solution might be to refactor our spaces completely. I think we'd need to move all objects into new spaces (basically break sets of privileges into separate spaces) and compose new parent spaces out of these, so I could make a do-everything space and a do-everything-except-access-code space.

We're open to clever solutions using the current tools if you have ideas, but it seems that this might be a gap in the spaces policies. Any thoughts/suggestions would be appreciated!

Event Timeline

I might not have read things carefully enough, but can you just add all the FTEs to "#yesrepo" and then use a positive policy to control access to Diffusion?

Well, now I just feel dumb. Haha. Yes, I think that would probably work, and I feel silly for not thinking of it since it has how I have been managing other privileges (i.e. Queue Managers, User Managers, etc.) Thanks!

epriestley claimed this task.

Cool -- I'd expect that to work in most situations. Let us know if you run into anything else weird.

Quick follow-up.. Any thoughts on the most efficient way to do a bulk add-to-group since the only obvious way to add users is via the autocomplete box from the members page for a project?

You can use project.edit to add members, roughly:

  • Look up all their PHIDs (maybe with user.query, or by selecting all the PHIDs out of some other project with
  • Apply a members.add transaction to the project via project.edit, adding all of them.

I can walk through that in more detail if you haven't run into that stuff before.

There's also T3980/T10621, but that's probably far-future-ish.

Got it. Was able to get the desired result using the Conduit API web UI and the calls you mentioned.