Set sub-space visibility to "Parent space members"

[psrpinto]

What would you like to do?

I would like to be able to automatically grant access to my sub-space to members of the parent space.

Why would you like to do it?

So that the sub-space is accessible to members of the parent space, without requiring the sub-space to be public.

How would you like to achieve it?

Be able to set the Visibility of a sub-space to "Parent space members". Right now it's only possible to set it to Public or Private.

[t3chguy]

You can do this only for subspaces created as such, not for spaces later added as subspaces.

Closing in favour of element-hq/element-meta#1961 which prevents supporting it for existing Spaces

[brevilo]

Hi @t3chguy,

You can do this only for subspaces created as such, not for spaces later added as subspaces.

is this limitation still in place? If so, what's "this" exactly? The availability of the "Space members" option itself or that it has an effect when used?

Background: I do have nested subspaces A > B > C with B and C having "Space members" enabled and their respective direct parent selected. As a member of A and B I'd expect to see C, e.g. in A's and B's space home, but I don't see it anywhere. Is that expected or should I open an issue?

Thanks

[t3chguy]

is this limitation still in place? If so, what's "this" exactly? The availability of the "Space members" option itself or that it has an effect when used?

Depends on when the space was created (its underlying room version)

Background: I do have nested subspaces A > B > C with B and C having "Space members" enabled and their respective direct parent selected. As a member of A and B I'd expect to see C, e.g. in A's and B's space home, but I don't see it anywhere. Is that expected or should I open an issue?

That doesn't sound expected, that list is populated by the server using the /hierarchy API not the client's own view of the space hierarchy

[brevilo]

A and B are version 10 and C is version 9, although I could have sworn C was created after A and B 🤷‍♂

Also, by "limitation" I meant that subspaces must be created off of their parents, not created independently and then added later as a subspace. Is that still the case with these room versions?

Thanks!

[brevilo]

A and B are version 10 and C is version 9, although I could have sworn C was created after A and B 🤷‍♂

Update on this part: this is a result of the difference in room creation my inquiry was all about. On our server m.room_versions[default] is 10, while m.room_versions[org.matrix.msc3244.room_capabilities][restricted][preferred] is 9. That means that spaces created separately (like A and B) will use room version 10, whereas subspaces directly created from an existing space and using the (default) restricted access mode (like C) will use version 9.

[brevilo]

You can do this only for subspaces created as such, not for spaces later added as subspaces.

@t3chguy, to ask my original question in a more nuanced way: given that I'm dealing with room versions 9 and 10 (see above) and given that the restricted join rule got added in version 8 already (refined in 9), making an existing v8+ space B a child of another v8+ space A and then setting B's join rule to restricted (on membership in A) should be readily supported, no?

Closing in favour of element-hq/element-meta#1961 which prevents supporting it for existing Spaces

Thus I presume your statement only applies to existing spaces with versions < 8 (which would have to be upgraded to v8+), correct?

If so, then I'd consider what I described originally to be a bug. Do you agree?

Thanks

[t3chguy]

If so, then I'd consider what I described #20015 (comment) to be a bug. Do you agree?

Yes. I said so.

That doesn't sound expected, that list is populated by the server using the /hierarchy API not the client's own view of the space hierarchy

It sounds like an issue with your homeserver's implementation of the hierarchy API.