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

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

I think this is just the same as T5046. You can use SSH, or wait for a fix for T5046.

See related to T5046

ohh, i see.

(The more-correct remedy is likely for the administrator to disable policy.allow-public or set the visibility of at least one space to "Public (No Login Required)" so logged-out users can see some objects.)

I just visited a site I don't have access to, so it should just say login or sign up.

I have two spaces, both are "All Users".

I don't think there should be any error message. I just visited a site I don't have access to, so it should just say login or sign up. The error message is about "Spaces" and "your account" which just seems confusing.

Do you have one Space, which is available to "All Users" instead of "Public"?

That worked. Thanks!

Try updating to after rP7c6320d21121 ?

ok

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?

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

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:

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.

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

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.