I'd just like to mention that Spaces support to Phriction was the first thing I wanted to do. I am about to restructure our wiki so we can make certain documents available to a subset of people involved in a project. My solution was going to be create another project for the subset of people then set documents with custom policies of members in both projects. This requires that we restructure the wiki though because of the inherited permissions of wiki pages. Conceptually it will be restructured into separate branches that represent "spaces".

this may be covered by the spaces system?

The visibility of a Space in our Phab instance is using a Custom Policy. When I click the red "Custom Policy" box, I am presented with this text, which does not help me at all:

Users with the "Can View" capability for this object:

haha, I was just looking for this task.

As far as I understand, this is how all View Policies work (that you can only set them to Projects you are a member of).

Yeah, I think this is sort of confusing, my understanding is:

We have a similar use case as Wikimedia's. We want the security team to CC people on tasks in Space:Security so that the CC'd people have viewing, editing, and commenting permissions, but don't have access to anything else in Space:Security. Is that possible?

We have a similar use case as Wikimedia's. We want the security team to CC people on tasks in Space:Security so that the CC'd people have viewing, editing, and commenting permissions, but don't have access to anything else in Space:Security. Is that possible?

after some further testing and using of ./bin/policy unlock of all relevant files this may not be the exact cause: I am certain though that creating such a file results in logged out users from seeing only a broken file while logged in I see it just fine.

Spaces are now available in master. They'll promote to stable in this week's release, and are likely to leave prototype next week.

Seems like the core is in at least roughly in a good place, now.

Development Log

Feeling pretty confident that T6860 was a really bad idea, so I threw it away; my current plan is to do T5135 instead, as described above.

We basically have two actual use cases in the wild here:

In the newer design, the space name has a red callout so it should be pretty hard to miss. Here's an example on the detail view:

I think this is a change we should probably pursue, and start with a color treatment as in T6787#88172. There are several technical challenges:

The clearly-desirable integrations now work. I want to wait for use cases for the others; they likely aren't technically hard, but are potentially bad/confusing/ambiguous.

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.

@epriestley: thanks for the heads up

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.

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

Turns out these are type-by-type, so yell if you see more and I'll just close this sooner or later if nothing turns up.

I actually can't reproduce this immediately now, either.

At this point, I'd guess this is probably something real dumb like us rendering the text forms of these wrong.

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

This now works, and the upstream has implementations for the reasonable-seeming use cases we've seen, particularly the policy that blocks T8488. This is relatively modular and extensible, but I don't think there are any other problems for it to solve right now.

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:

@20after4, D13252 changes the signature of two methods in PhabricatorPolicyRule:

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?

We want this for T8488 and it's probably a component in moving T8434 forward.

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.