The "strongest policy" thing landed a few days ago and can be seen on T8514, for example (policy hint says "Space Test Users" even though the object policy is weaker, and clicking it explains why, although on the redesign the dialog formatting is a little messy). I think this is a pretty reasonable approach that adds clarity without being less powerful, but let me know how it feels. There's also a stronger color for the space name in headers now in the redesign. That's still in flux, but feels pretty good to me.

In T8434#121407, @20after4 wrote:

Regarding editing policy on a task: I'm not sure how to do it but I think what might be desirable is that the task author has some sort of limited ability to comment on a 'security' task but not really edit it in any significant way after submission.

The form templating stuff sounds really cool.

Reduce PolicyRule Hackiness + Support Templating Custom Fields would probably serve our needs well and it would also be useful, I'd imagine, for other installs to implement their own custom access controls.

Just to keep this up to date, I had a bunch of other personal/company stuff for the last couple of days so this hasn't moved forward much during that time, although clicking a policy link does show space information now. I have made it most of the way through the "show the strongest policy" thing above, at least, and that'll probably land today.

Development Log

On the second part, from IRC:

In T8376#120613, @epriestley wrote:

In Wikimedia it occasionally happens that we do things in private ... but usually the fact that we're working on something in private isn't private in itself

In Wikimedia it occasionally happens that we do things in private ... but usually the fact that we're working on something in private isn't private in itself

In T8376#120442, @epriestley wrote:

I think that there should be a separate visibility policy for the description page of a space.

Can you walk me through this a little more? I'm hesitant to add complexity, and it seems like having "Can See Space" and "Can See Objects in Space" as separate policies may be confusing. Why is it important/desirable that users be able to see, e.g., a "Procurement" space if they don't have access to it?

My rough idea is to invert the colors, so there would be a solid color with the space name in white, then the object name. I planned on experimenting with this in the redesign since the white headers have more flexibility.

I think that there should be a separate visibility policy for the description page of a space.

Oh, and on these cases:

The rest of Spaces is on more solid ground, now, so I'd like to keep working on a path forward here.

I think that there should be a separate visibility policy for the description page of a space. I think that the text shown for visibility policies at the tops of objects should be clarified when in spaces. I can't think of any other tweaks right now other than the things discussed in T8434, which are more major. I think here's already some consideration about how objects in spaces should look style-wise somewhere?

any design improvements I'd probably push into the redesign (I have several ideas for Object pages as is, but they don't work on existing UI).

Development Log

@Krenair, maybe you just don't have your preferences configured on this install in the way you expect? From the logs, it looks like you were sent mail with links in it:

Maybe -- it's linked for me, and I would expect it to be linked for you because you have access to the space:

Noticed that S2 did not get linked in the email for @epriestley's above comment, is that a bug?

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.

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

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"?