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.

Development Log

Total Hours: 9

Available Now

• Spaces is now a real (prototype) application, but doesn't do anything useful yet.

Discussion

The core application build went smoothly and is substantially complete. It will get more features and polish later on.

The extended policies changes (to fix T7703) went very smoothly and are substantially complete, although there's still some nontrivial work remaining to support "or/any" extended policies, as in Files. Extended policies will be integrated more widely later on.

The mail policy changes (to fix T6367) have gone more slowly than I estimated. The major challenge I've hit is that I didn't anticipate the complexity of performing policy checks properly for mailing lists. T8387 has discussion and resolves this by converting mailing lists into pseudo-users. Work is mostly complete.

Next Up

I'm going to finish T6367 and begin implementing Spaces checks into the core policy infrastructure. This is still mostly infrastructure groundwork, but may get some UI if I get far enough.

Development Log

Total Hours: 9

Available Now

• Guidance on the mailing list migration is available in T8398.
• T6367 (respect policies and languages in mail) is now available in HEAD and deployed on this server.

Discussion

Tied up loose ends in T6367 and T8387 which were tactical priorities for the upstream and have some tangential bearing here, but were far afield from the scope of this task.

Next Up

Spaces checks in the core policy infrastructure.

Development Log

Total Hours: 13

Available Now

• None of the new stuff is user-facing yet.
• D13159 has some screenshots but hasn't landed.

Discussion

After D13159, Spaces technically work, but in a very limited way and only in Paste. This all went cleanly.

We have more clarity now about how Spaces work technically, and are starting to think concretely about the "Security" use case (where users can see some objects in a Space, but not others -- for example, security bugs they've filed).

I'm less sure that we want to pursue this by adding additional rules to Spaces than I once was. In D13156, I've pursued the most aggressive policy implementation available for Spaces (the policy barriers around a space are as absolute as they can be). This feels really good (easy to use/understand, predictable) from a product perspective and is desirable from a technical perspective because it allows us to filter Spaces more efficiently (at the Query level in the database, instead of in the application: we can just throw away objects we know the user can't see without having to process them).

Adding rules to make Spaces implement less agressive policies currently feels flimsy and confusing to me from a product perspective, and requires us to compromise the performance benefits partially or completely from a technical perspective. This motivates exploring alternatives to address the "Security" use case.

There's some more discussion in D13156. Particularly, @btrahan suggested that Nuance is probably a better long-term solution to this class of problem, which I tend to agree with. I want to evaluate whether it can be a better short-term solution to this class of problem, too.

Next Up

Evaluate and present Nuance as an alternate solution to the "Security" use case.

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

• S1 Core
• S2 Test Space

S2 is only visible to members of Space Test Users. So you can:

• Try to see S2 or P1798.
• Presumably, be unable to see them.
• Join Space Test Users.
• Now, you'll be able to see S2 and P1798.

(S2 doesn't link up yet, but will before too long.)

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

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

Today, policies are technically powerful enough to express these access controls, but applying policies to a large group of objects is inconvenient, time consuming, error-prone, and lacks support tooling. The workflows to support these cases today are so absurdly labor-intensive and error-prone that human users can not realistically use them. Some examples of cases that are particularly difficult to solve today include:

• If a company wants to give contractors access to only a few objects, they currently must go add a policy restriction to every other existing object. This is an impractically huge amount of work. They must then continue adding policy restrictions to ever new object going forward. Basically, this is completely absurd and no organization could realistically sustain it.
• If a company wants to separate objects per-client, they need to carefully remember to always set policies appropriately when creating new objects, and educate clients on how to do this, and clients always need to do it.
• There is no way to search for objects with a specific policy, and you usually need to look at each object individually to understand its policy settings.
• It's easy to forget to change a policy or set a policy incorrectly, and difficult to detect the error.
• There's no layer of indirection between the intent of the policy and the implementation of the policy, so if you change the definition of the policy later you need to do an unrealistically huge amount of work to update it.

So the major goal here is just to add tools to make these groups of objects with a common policy easy to create, find, manage, and understand. The mechanics of policies aren't changing much, we're just improving the tooling so humans can realistically navigate these use cases.

The only technical difference is that Space policies are the strongest policies -- stronger than automatic policies -- so users can not see objects in a Space they can not see, even if they are the owner of a task or author of a revision.

Spaces don't really let you do anything you can't already do, but you'd need to fiddle with a huge number of policy controls and never make a mistake to do certain things right now that are a lot easier with Spaces.

Thanks, good explanation.

Development Log

Total Hours: 17

Available Now

• Spaces S1 Core and {S2} exist on this install.
• Join Space Test Users to get access to {S2}.
• Pastes can be put into spaces and filtered by spaces.
• Spaces have basic integration with remarkup rules, hovercards, and list views.

Discussion

After discussion, it seems like we don't need a way forward on T8434 immediately, so I'm focusing elsewhere until we have a more concrete sense of the tools Spaces will offer.

I've been working on search integration. This has been smooth so far, but I haven't done Maniphest yet (which is much more complex).

I wrote a few rough UI integrations. We're still tossing around design approaches internally and may change how these look substantially, they're just trying to get the right data in approximatley the right place.

Next Up

I plan to do search integration for Maniphest, then start bringing Spaces to other applications outside of Paste.

Development Log

Total Hours: 22

Available Now

• Some applications now have more search controls.

Discussion

Infrastructure changes that either directly converted applications which are getting Spaces support to SearchFields, or fixed issues with infrastructure Maniphest uses.

This also cleared out the messy part of T7909, although I think that's obsolete now.

Next Up

Finish moving Maniphest to SearchFields, then start bringing Spaces to more applications.

Development Log

Total Hours: 23

Available Now

• Nothing in HEAD quite yet.

Discussion

These integrations were straightforward; these applications don't have many behaviors which directly interact with Spaces.

I adjusted some of the UI behaviors in D13229 to try these approaches out. Specifically:

• Spaces edit control combined with "Visible To" policy control.
• Don't label objects in the default space when browsing (theory: most objects are probably usually in this space, so it's more useful to just show exceptions).
• Don't label objects if the user only has access to one space ("in space jail", theory: these are clients / consultants whose world starts and ends in the space, so omitting it reduces clutter?).

These aren't necessarily final, but feel like steps forward in usability/clarity right now.

Next Up

I'm planning to refine Spaces themselves next (descriptions, ability to archive them, likely icons) and then probably do the "Herald Condition" and "Application Email" integrations.

Development Log

Total Hours: 25

Available Now

• Maniphest and Pholio support are in HEAD and available on this server.

Discussion

Implemented a couple of features and refined some minor behaviors.

Next Up

I plan to finishing the "Application Email" integration next.

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.

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

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

I'll see if I can reproduce that locally.

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

$ ./bin/mail show-outbound --id 709545
PROPERTIES
ID: 709545
Status: sent
Related PHID: PHID-TASK-ctbwbhgwgochzkbzbzzh
Message: 

PARAMETERS
subject: T8376: Develop Spaces (v1)
from: PHID-USER-ba8aeea1b3fe2853d6bb
subject-prefix: [Maniphest]
vary-subject-prefix: [Updated]
thread-id: maniphest-task-PHID-TASK-ctbwbhgwgochzkbzbzzh
is-first-message: 
exclude: []
herald-force-recipients: ["PHID-USER-vg42yoljioxdv5iac3py"]
mailtags: ["maniphest-other","maniphest-comment"]
is-bulk: 1
reply-to: <...>
to: ["PHID-USER-462xomdaog6qjw4uockx"]

HEADERS
Thread-Topic: T8376: Develop Spaces (v1)
X-Herald-Rules: <79>, <85>, <103>, <105>
X-Phabricator-Projects: <#prioritized>, <#policy>, <#wikimedia>, <#spaces>
X-Phabricator-To: <PHID-USER-ba8aeea1b3fe2853d6bb>
X-Phabricator-Cc: <PHID-USER-f1ca174bb6af9391a5f7>
X-Phabricator-Cc: <PHID-USER-vg42yoljioxdv5iac3py>
X-Phabricator-Cc: <PHID-USER-ees56kwwguslhqwe254y>
X-Phabricator-Cc: <PHID-USER-jtzqmxzqel3bvt4flxen>
X-Phabricator-Cc: <PHID-USER-jmvolb7vo5qolixkccuq>
X-Phabricator-Cc: <PHID-USER-3yc34eijivr6rqs4vgiw>
X-Phabricator-Cc: <PHID-USER-p7rr2g5lhpjpxaqvhykr>
X-Phabricator-Cc: <PHID-USER-p2axfzcmoluit7llpzt2>
X-Phabricator-Cc: <PHID-USER-462xomdaog6qjw4uockx>
X-Phabricator-Cc: <PHID-USER-7m5vr3h2wgau5fjkabs3>

RECIPIENTS
  Krenair (Alex Monk)

TEXT BODY
epriestley added a comment.

Per https://secure.phabricator.com/T8498, you can now send mail to `test-space-bugs@phabricator.com` to create tasks directly in https://secure.phabricator.com/S2 (join #test_space_users first if you can't see it). https://secure.phabricator.com/T8514 is an example.


TASK DETAIL
  https://secure.phabricator.com/T8376

EMAIL PREFERENCES
  https://secure.phabricator.com/settings/panel/emailpreferences/

To: epriestley
Cc: btrahan, aklapper, devurandom, cburroughs, eadler, joshuaspence, jdloft, qgil, Krenair, jeremyb


HTML BODY
<div>epriestley added a comment.</div><br /><p>Per <a href="https://secure.phabricator.com/T8498" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">T8498</a>, you can now send mail to <tt style="background: #ebebeb; font-size: 13px;">test-space-bugs@phabricator.com</tt> to create tasks directly in <a href="https://secure.phabricator.com/S2" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">S2</a> (join #test_space_users first if you can&#039;t see it). <a href="https://secure.phabricator.com/T8514" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: line-through;" rel="noreferrer">T8514</a> is an example.</p><br /><div><strong>TASK DETAIL</strong><div><a href="https://secure.phabricator.com/T8376" rel="noreferrer">https://secure.phabricator.com/T8376</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://secure.phabricator.com/settings/panel/emailpreferences/" rel="noreferrer">https://secure.phabricator.com/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>epriestley<br /><strong>Cc: </strong>btrahan, aklapper, devurandom, cburroughs, eadler, joshuaspence, jdloft, qgil, Krenair, jeremyb<br /></div>

Compare to mail sent to @qgil, who is not in the project and can not see S2:

$ ./bin/mail show-outbound --id 709544
PROPERTIES
ID: 709544
Status: sent
Related PHID: PHID-TASK-ctbwbhgwgochzkbzbzzh
Message: 

PARAMETERS
subject: T8376: Develop Spaces (v1)
from: PHID-USER-ba8aeea1b3fe2853d6bb
subject-prefix: [Maniphest]
vary-subject-prefix: [Updated]
thread-id: maniphest-task-PHID-TASK-ctbwbhgwgochzkbzbzzh
is-first-message: 
exclude: []
herald-force-recipients: ["PHID-USER-vg42yoljioxdv5iac3py"]
mailtags: ["maniphest-other","maniphest-comment"]
is-bulk: 1
reply-to: <...>
to: ["PHID-USER-p2axfzcmoluit7llpzt2"]

HEADERS
Thread-Topic: T8376: Develop Spaces (v1)
X-Herald-Rules: <79>, <85>, <103>, <105>
X-Phabricator-Projects: <#prioritized>, <#policy>, <#wikimedia>, <#spaces>
X-Phabricator-To: <PHID-USER-ba8aeea1b3fe2853d6bb>
X-Phabricator-Cc: <PHID-USER-f1ca174bb6af9391a5f7>
X-Phabricator-Cc: <PHID-USER-vg42yoljioxdv5iac3py>
X-Phabricator-Cc: <PHID-USER-ees56kwwguslhqwe254y>
X-Phabricator-Cc: <PHID-USER-jtzqmxzqel3bvt4flxen>
X-Phabricator-Cc: <PHID-USER-jmvolb7vo5qolixkccuq>
X-Phabricator-Cc: <PHID-USER-3yc34eijivr6rqs4vgiw>
X-Phabricator-Cc: <PHID-USER-p7rr2g5lhpjpxaqvhykr>
X-Phabricator-Cc: <PHID-USER-p2axfzcmoluit7llpzt2>
X-Phabricator-Cc: <PHID-USER-462xomdaog6qjw4uockx>
X-Phabricator-Cc: <PHID-USER-7m5vr3h2wgau5fjkabs3>

RECIPIENTS
  qgil (Quim Gil)

TEXT BODY
epriestley added a comment.

Per https://secure.phabricator.com/T8498, you can now send mail to `test-space-bugs@phabricator.com` to create tasks directly in S2 (join #test_space_users first if you can't see it). T8514 is an example.


TASK DETAIL
  https://secure.phabricator.com/T8376

EMAIL PREFERENCES
  https://secure.phabricator.com/settings/panel/emailpreferences/

To: epriestley
Cc: btrahan, aklapper, devurandom, cburroughs, eadler, joshuaspence, jdloft, qgil, Krenair, jeremyb


HTML BODY
<div>epriestley added a comment.</div><br /><p>Per <a href="https://secure.phabricator.com/T8498" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">T8498</a>, you can now send mail to <tt style="background: #ebebeb; font-size: 13px;">test-space-bugs@phabricator.com</tt> to create tasks directly in S2 (join #test_space_users first if you can&#039;t see it). T8514 is an example.</p><br /><div><strong>TASK DETAIL</strong><div><a href="https://secure.phabricator.com/T8376" rel="noreferrer">https://secure.phabricator.com/T8376</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://secure.phabricator.com/settings/panel/emailpreferences/" rel="noreferrer">https://secure.phabricator.com/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>epriestley<br /><strong>Cc: </strong>btrahan, aklapper, devurandom, cburroughs, eadler, joshuaspence, jdloft, qgil, Krenair, jeremyb<br /></div>

Notably, you were sent these text and HTML bodies:

...create tasks directly in https://secure.phabricator.com/S2...
...color: black;text-decoration: none;" rel="noreferrer">S2</a>...

He was sent these unlinked bodies:

...create tasks directly in S2...
...</tt> to create tasks directly in S2...

Development Log

Total Hours: 29

Available Now

• Application email now supports Spaces.
• Spaces can be adjusted with the Maniphest bulk editor.
• I wrote part of a charming short story about Spaces.

Discussion

Spaces substantially work now, and I'm interested in feedback on how they feel so far. In particular, I'd like any feedback on these areas:

• What's the most useful approach for the "switcher" UI?
• The design and UI are still unpolished, but do they mostly feel reasonable?
• How should we move forward on T8434?

Switcher UI: See T8442 for details. Currently, you can't change the default space that new objects you create are created into. You also can't temporarily "turn off" some Spaces, or "focus" on a specific Space (turning off all other Spaces). It's not clear if these capabilities are really important/useful or not, particularly the hide/focus capability (you can always filter search results to specific Spaces). Some possible approaches might be:

• Do nothing (maybe none of these capabilities are actually very useful).
• Add a "Set default..." option to the Space selector dropdown itself, if setting a default is useful but rare and hiding/focusing spaces is not very useful.
• Add a global menu item with options to set a default space and possibly hide or focus on spaces (if setting a default is useful and common, and/or hiding/focusing spaces is useful).

I'm interested in feedback on either how useful these capabilities are anticipated to be, and particularly on how desirable they feel in practice.

Design: I currently think the design/UI are in relatively good shape. I'd like to improve the visibility of Spaces on objects detail pages a little bit, and give the space selector dropdown which is bundled with the policy control a more consistent style, but things feel like they're in the right ballpark to me.

I'm interested in feedback either on this being a general consensus (everything is basically good, could use a few tweaks here and there), or elements of the design/UI feeling farther off-kilter (for example, the element on detail pages feeling substantially unclear or like it needs a major increase in prominence, or other things being confusing or unintuitive).

Moving Forward: I'll follow up on T8434; I think this is the last real piece with a major technical component.

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

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?

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?

I think that the text shown for visibility policies at the tops of objects should be clarified when in spaces.

Can you maybe give me an example of what you mean? Specifically, I'm not sure what you mean by "clarified". Currently, it says something like this:

Secret Project | Collect some acorns

Do you mean that you feel that "Secret Project" lacks clarity, and it should instead look more like:

Space: Secret Project | Collect some acorns

Or something else?

I think here's already some consideration about how objects in spaces should look style-wise somewhere?

I currently expect them to look relatively similar to how they look now. There will be broad changes to elements after T8099 and then probably some minor adjustments to improve the appearance, but we're probably talking about stuff on the scale of spacing/color changes (I'm not completely sure how ambitious @chad's ideas are).

T8442 experimented with just using an icon, but I felt like this was a step backward (much less clear and created visual clutter).

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.

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?

In Wikimedia it occasionally happens that we do things in private (security, other uncommon sensitive stuff), but usually the fact that we're working on something in private isn't private in itself (ew, meta-secrecy?), and usually some general information about the activity is public (i.e. the fact that operations has a procurement system is public, it's been mentioned several times in the past on our public Phabricator instance, but the details of individual cases are very very private. As far as I know they still run this process through RT?)

I think that the text shown for visibility policies at the tops of objects should be clarified when in spaces.

Can you maybe give me an example of what you mean?

Sure. So right now, P1798 and T8514 are in S2, which is hidden by default (you have to join a project to see them). However, they still show "Public" at the top (object visibility) if you meet the space's policy for visibility. It's not at all clear to non-power users that really the restrictive space policy applies as well. I am not a lawyer (and I do not represent any particular Wikimedia organisation when speaking here - I am a volunteer and this is my personal account), but I suspect that when things such as confidentiality agreements come into play, and it looks like you're being presented with something public due to this (even though it's really super-private and supposedly protected under such an agreement), this is bad. To be honest this applies to any use of spaces, not just where such agreements apply, but I feel it is one of the more serious cases (and most relevant to what appears to be your target audience for a lot of Phabricator Policy stuff - corporations).

What about showing 'Custom Policy' instead, and detailing the space policy as well as the object policy in the popup?

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

Given that the number of spaces will presumably be small (e.g., <10/year?) and their creation will presumably be tightly controlled, maybe you could just maintain a separate document explaining how the install uses spaces in order to satisfy this?

The audience for "what spaces exist?" is probably different from the audience for "how to use this space" anyway, and maybe communicating to them differently is appropriate. And since they have sequential IDs someone should catch any missing spaces sooner or later (e.g., if S7 is documented, but S6 isn't, that's a hint to go figure out what S6 is).

This is a little low-tech and isn't ideal in your use case, but doesn't seem totally unreasonable to me given how slowly I anticipate spaces being added (of course, I'm not the one who would have to do the work, and maybe you'll actually have thousands of spaces).

It's not at all clear to non-power users that really the restrictive space policy applies as well

The hope, at least, is that users will be able to learn what the Test Space | header means pretty quickly. After D13264, clicking "Public" will also include text like "This object is in the space Test Space, and can only be seen by users with access to that space." to help reinforce this.

An earlier iteration did try to put this information directly adjacent to "Public" (see D13159) because they're closely related, but it felt easy to miss, cluttered, not clearer for new users, and worse for experienced users.

I think this is partly a problem with the "Public" element itself, although I'm not sure how to resolve it. "Public" (or whatever else) almost never means what it says because of object policy exceptions (which increase access) application policy rules (which reduce access), and now because of Spaces.

For example, in Differential, the hint may say "Members of X", but it really means "Members of X who can see rY, plus the revision author regardless of whether they are a member of X or can see rY, but, in all cases, only if they can see objects in space Z.". But we can't fit that into the header without making things a lot worse for experienced users.

These rules are explained if you click the link. Although this does cause some confusion, it doesn't seem to cause a huge amount of confusion right now (it's possible that spaces may increase the amount of confusion this causes, though).

We could replace this text with something along the lines of "Click to Understand Who Can See This Object" (probably in fewer words, like "Show Rules"): that is, stop showing the hint about visibility. I think this would be less confusing for new users (the element would never miscommunicate), but it would also be less useful for experienced users (the element would cease communicating anything).

This element isn't hugely useful for experienced users anyway (see T6787 for some discussion) but it feels lazy and suboptimal to just give up on by making it show nothing useful or almost always say "Custom Policy". I'd like experienced users to be able to understand the policy settings for an object at a glance in nearly all cases.

I'm not sure how to improve this element while balancing these concerns. I think the current balance isn't bad: I currently believe that new users are occasionally a bit confused (but some level of confusion is essentially unavoidable), and experienced users can generally understand policies at a glance. Even an object in a Space may still be completely public, too, as this object (T8376) is: the containing space ("Hyperspace") is completely public.

One possible approach, which still feel lazy, is to always qualify the words. For example, we could write Public, with Additional Rules on every object instead of Public. This isn't as bad for experienced users as writing out everything or degrading the element to just saying "Custom Policy", but still feels worse for them. I'm also not sure it would really help newer users very much.

There's also tension between the space UI simplifications we use and communicating policies clearly. In particular, if you only have access to one space, we generally don't show you that spaces exist. This might be particularly confusing in the "Consultants" or "Clients" use cases, because the UI won't show the hint that the object is in a space. As written, D13264 won't show the hint in the dialog, either.

Maybe after T6787 we instead show "Standard Rules" in most cases, and "Special Rule: X" in cases where the object has a non-default policy.

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

Sounds good enough to me. We can have i.e. a panel in our Wikimedia Phabricator homepage introducing the Spaces, including a link to learn more in our own Phabricator documentation.

On the second part, from IRC:

epriestley: Krenair: one thing we could do is this:
epriestley: We can't define a total ordering on policies, because "custom policy X" and "custom policy Y" aren't necessarily stronger or weaker than one another, but we can partially order them:
epriestley: Public >= All Users >= (All non-custom policies)
epriestley: If an object is in a space we can compare the space policy and the object policy. If there's a strict ordering on them, we can show the stronger (more restrictive) policy.
epriestley: You could still end up with cases where the object policy is shown when the space policy is more restrictive in practice (for example, object policy is "employees" and space policy is "c-level employees") but I think those should be relatively rare.
Krenair: you'd want it to be clear where the policy is coming from, maybe that's something that can be clarified when you click the policy's link
epriestley: Yeah, there's a diff out for half of that; we could add a line there to make it more clear.
Krenair: but otherwise that might work

This seems pretty reasonable to try to me.

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.

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.

My plan for moving forward is:

• Let this sit for a bit longer for any major feedback. I'll drop a note on the parent task / changelog too, probably at the end of the week.
• Introduce support in a couple more applications outside of WMF scope (Repositories is the big one so we can test this out ourselves a bit more, maybe Passphrase since I think it's pretty simple).
• Unprototype the Spaces application.

If there's more testing or discussion happening on the WMF side which might spur substantial changes, it's slightly preferable to get that feedback before we unprototype. Not a big deal either way, but if holding the formal release for a bit makes sense we can wait as long as you want. Otherwise, I'd tentatively plan to unprototype the application some time the following week (that is, the week of the 29th).

I think we probably won't have a very good idea about how the "switcher" UI should work until this gets some use in production, so I'd anticipate building that a bit later once we have a better sense of where the pain points and use cases are. There's nothing technically complicated about it and I think it'll take about an hour to put together, there's just a very large UI design space and I'd like a better sense of where the target is. It's also possible we don't need to build this at all.

It looks like incremental improvements are promising for T8434, so I'll continue pursuing those (Herald select field conditions, basic improvements to templating). These should happen this week. We'll start using object policies in the upstream this week too, which should hammer out any remaining issues with them.

Development Log

Total Hours: 31

Available Now

• Tasks with non-default policies now have a UI callout. For example, see T8641.

Discussion

Design on that "non-default policy" thing is likely nonfinal, particularly in the redesign branch, and we might try alternate UI treatments, but the groundwork to determine when policies differ from the defaults is in.