Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rooms cannot be restricted (allow access) to spaces they are not part of #19213

Closed
rda0 opened this issue Sep 28, 2021 · 5 comments · Fixed by matrix-org/matrix-react-sdk#9017
Assignees
Labels
A-Room-Settings A-Spaces Spaces, groups, communities O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect X-Needs-Product More input needed from the Product team

Comments

@rda0
Copy link
Contributor

rda0 commented Sep 28, 2021

Steps to reproduce

  1. Create a private room (not in a space)
  2. Upgrade it to version 9
  3. Try to restrict it to a space in Room Settings > Security & Privacy > Access > Space members

What did you expect?

Allow to restrict rooms to all spaces my client knows about.

What happened?

The UI does not show any spaces to restrict to:

image

Similarly if the room is part of a space, it cannot be restricted to another space that it is not part of.

Workaround

Use /devtools to manually edit m.room.join_rules, which then shows the space with access in room settings:

image

Edit which spaces can access here. still does not show the space restriction:

image

Operating system

Windows

Application version

Element version: 1.9.0 Olm version: 3.2.3

How did you install the app?

https://element.io/get-started

Homeserver

phys.ethz.ch

Have you submitted a rageshake?

No

@rda0 rda0 added the T-Defect label Sep 28, 2021
@SimonBrandner SimonBrandner added A-Room-Settings A-Spaces Spaces, groups, communities O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist labels Sep 29, 2021
@t3chguy
Copy link
Member

t3chguy commented Sep 29, 2021

This was done intentionally to make that list as minimal as possible, given that allowing joins from users in space X if the room isn't in space X then how would users even discover that room

@t3chguy t3chguy added the X-Needs-Product More input needed from the Product team label Sep 29, 2021
@rda0
Copy link
Contributor Author

rda0 commented Sep 29, 2021

This was done intentionally to make that list as minimal as possible, given that allowing joins from users in space X if the room isn't in space X then how would users even discover that room

It could be discovered in space Y or any other way (room aliases/ids, matrix.to links).

I thought so that it was done intentionally and I think it probably makes sense for the majority of space usage cases. What about a check box Show all spaces, that is off by default or hide them behind an advanced section?

@niquewoodhouse
Copy link

I thought so that it was done intentionally and I think it probably makes sense for the majority of space usage cases.

just to check, please, @rda0 what's the use case that you have here? Thanks so much

@rda0
Copy link
Contributor Author

rda0 commented Nov 1, 2021

I thought so that it was done intentionally and I think it probably makes sense for the majority of space usage cases.

just to check, please, @rda0 what's the use case that you have here? Thanks so much

@niquewoodhouse I am a server admin in a university. Our simplified organizational structure looks like uni > n departments > n institutes > n research groups. Typically a research group wants a private space and private rooms in them to communicate. Most of our rooms are private, most of our rooms would like to be restricted. People sometimes would like to have an option to create rooms that are accessible by uni/department members only. Our university is very federated (both physically and organizational). Our Matrix users are federated over multiple servers on uni and department level. We have a relatively high fluctuation of memberships in those organizational structures.

In an ideal world and if the following features are ready (out of beta) or implemented:

building a huge tree of spaces reflecting our structure would make this issue go away, since you can restrict rooms in Element to parent spaces. Although I have doubts that it will ever be possible to organizationally manage such a spaces construct.

I think just restricting a room to space X without having all the subspace organizational complexity is much simpler for the end user. Of course we can instruct our users to use the /devtools. But regular people (not developers or Matrix admins) do not like to use /devtools or to type json.

As a Matrix admin I would like to have more features in my client rather than less. I would like to be able to use all features of the Matrix protocol using the clients UI.

@luxaritas
Copy link

luxaritas commented Dec 22, 2021

I'd also like to jump in with a use case: I'm on a project where some of our code is open source, but not all of it. My desired hierarchy is like:

My Project
- General Discussion
- Core Team
- Development
  - Public Subproject
  - Private Subproject

The "private subproject" room should only be available to members of the core team, but I don't want to have to add the development space as a subspace of core team as it should be considered a high-level space under my company, as it is accessible to public members of the project as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Room-Settings A-Spaces Spaces, groups, communities O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect X-Needs-Product More input needed from the Product team
Projects
No open projects
6 participants