Well that can't actually happen in full for Security or WMF-NDA until Spaces allow you to bring individual users into individual objects regardless of space policy.

I'm not sure how much I'd trust a !space command to be honest.

In T8493#119801, @qgil wrote:

the intention is that Spaces will allow us to deprecate our own local remedies, one step at a time.

(@Krenair, yes, the intention is that Spaces will allow us to deprecate our own local remedies, one step at a time.)

In T8493#119789, @epriestley wrote:

I think the difference with the Wikimedia Procurement use case is that tasks with files are created via email (i.e. a provider sends an offer to an email address).

I hadn't thought about this yet, but I think we'll probably just let you assign a Space to each application email address, so everything to procurement-bugs@ would default into the procurement space and everything to normal-bugs@ would go into the default space.

(We can implement a !space mail command, too, if there are automated or more complex cases here where the same address might receive mail destined for multiple spaces.)

I think the difference with the Wikimedia Procurement use case is that tasks with files are created via email (i.e. a provider sends an offer to an email address).

In T8493#119786, @epriestley wrote:

I created a test task (T8497) which only I can see, then I replied to it via email.

At HEAD, the underlying use case discussed on that task should already be secure:

The workflow you showed is perfect, thank you. At least in Wikimedia nobody has asked for separate queues and I don't think anybody needs them.

Here's how it works slightly-ahead-of-HEAD:

Since "Assigned" is a search query, I'll ask here just in case:

At least for Wikimedia, Files clearly wins over Pholio. While our design workflows are usually public, we have several private workflows where the most private part is a document attached (a file).

I believe this is effectively complete. We'll probably look at revising the control itself at some point, but I think it's likely fine until we do a more complete iteration on these UIs as part of T6943.

Development Log

I think these are the plausible-ish icons that we aren't using anywhere else yet -- this might be missing icons or have icons we can't really use:

I really like how that looks.

Development Log

Tossing out an idea, if user has access to more than one space, header - eye turns into a Space switcher? Sampled here with OPS and Security, allowing users to set header color / icon for space.

In T8434#118779, @epriestley wrote:

I'd ideally like to do this via T4411, but we could also meet halfway via T5681: that would let you write a "subscribers to this object" rule instead of needing to write a "subscribers to [explicitly, type in this object with your keyboard]" rule, which might simplify things a little bit, at least. (I assume the "type in this object" part is sort-of-automated via secret magic right now, at least some of the time, so maybe this is only very slightly nice-to-have.)

Thanks, good explanation.

Excerpted from a giant novel I wrote but didn't bother publishing:

What's the difference between putting something in a space and setting the visibility of an object to "members of some project"?

A very rough version of things is available to play around with on this install, now. I've created two spaces:

Note that you'll be able to search for objects in a specific space using the query interface (T8441) independent of any global settings. So you can always explicitly search for stuff in the "Operations" (or whatever else) space, the product question here is just whether we need additional global/default settings to make "switching into a space" an (optionally) more all-consuming operation.

Thanks for writing that up!

We spent so much time on this it's almost nostalgic now :)

(This is only partially blocked by work described in T7715, but I'm linking it here for completeness and to make it easier for me to dig up.)

In T8434#118735, @Krenair wrote:

So... you propose that we simply kill the ability to add specific users to specific private tasks, is that right?

Users who don't understand it. And - off the top of my head - I'd quite like our custom 'security' option simply be the name of a pre-defined policy (we don't want unprivileged users to be able to set arbitrary policies, that can only result in a mess), but I haven't really thought through all of the implications of this.

In T8434#118741, @aklapper wrote:

In T8434#118719, @Krenair wrote:

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context

It can be desirable. Being able to exclude reporters/ commenters on certain tasks from certain updates is very useful for handling procurement requests (such an RT feature was used at least by Wikimedia's Operations team).

In T8434#118738, @epriestley wrote:

How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?

Fine with me personally, that was the system in BZ. I do wonder what Chris thinks about this now though.

In T8434#118719, @Krenair wrote:

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context

From https://phabricator.wikimedia.org/T76401, maybe that's actually ideal/desirable, and @chasemp's concerns aren't related to this use case (or perhaps are allayed by "hard spaces")?

How would you like the flow where you give permission to new users to work? In T4411, @chasemp expressed some concerns about using CC/Subscribers for this (particularly, that users can add other users to CC). Do you share those concerns, or is adding users to CC to give them rights satisfactory for you?

In T8434#118721, @qgil wrote:

In general I also like the concept of "hard spaces", simpler to understand
and to protect.

There is this "misuse" case that hard spaces would about: Security team
member leaves the team for some reason while staying as a regular
contributor.... but keeps access to old tasks that he authored. It is
simpler if you are either in our out.

unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter

In general I also like the concept of "hard spaces", simpler to understand
and to protect.

In T8434#118707, @epriestley wrote:

• The original reporter can not see the task or any work done on the task, only the separate discussion on their original report. This allows security response to be separated from communication with the reporter.

That does not sound desirable to me in our context (unless the Nuance entry was basically just a special task, where we could have to option to continue as normal while including the reporter), what do you think @csteipp?

Development Log

Yeah, the "Security" use case is letting users see objects in a Space they normally don't have access to because they have some special relationship to those objects (for example, giving users access to security tasks if they reported them).

I read the Nuance description, but it is still unclear to me what it does.

Development Log

Development Log

Since this is a relatively large task that's likely to end up with a hundred thousand subtasks, I'll try to summarize progress here periodically.