Development Log

Tangential, and feel free to ignore if here and now it's not appropriate: in the lines of T6787: Clarify UI for Objects with a non-default Policy, I think it would be useful to have a clear visual cue signaling that you are in a non-public space.

I poked at this a bit, but it doesn't feel great to me, at least with the current header design:

In T8442#119852, @epriestley wrote:

I'm also still not totally sure that we need/want icons.

I'm also still not totally sure that we need/want icons. I'm probably going to do a diff where we just use the icon everywhere and see if that looks reasonable or not. If it's better than names, we can go from there.

Hmm.. I'm not sure if we'd pick up enough generic/flexible icons to justify adding it. A lot of the icons seem not-generic-enough or duplicated in Font Awesome.

Have you looked at Google's free font icons? Lots of geeky, boring ones in there might be good for spaces or badges without overlapping our current set if that's your concern.

After thinking about this, I sort of like reserving some of the more geometric shapes for Badges (T6526), since v1 is probably going to have to use icons.

Development Log

That's not how I read T3820#116906

This looks like it's done, although we may revisit it after T8434 has a more solid path forward.

Edit: Ignore this. Your quote formatted strangely in my email client and I thought you were saying that Spaces do allow that. Never mind.

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

And the ability to actually see custom policy details such as the one for our "Can Edit Task Projects" Maniphest application policy please.

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 case it's helpful: Here's a real-world use case: custom policy rule I wrote to allow "Subscribers of this task" WMFSubscribersPolicyRule

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