[Task] iOS: Space's security & privacy section is not shown correctly

[mxandreas]

It is assumed that the user needs to have m.room.join_rules and m.room.canonical_alias permission to show them the Security & privacy section.

However, there were cases found:

• when user was not shown this section, even if they had those permissions (depending on what the other permissions were, either the entire Settings was unavailable or just the Security & privacy section was unavailable).
• when the user was shown this section, even if they did not have those permissions.

The details of which permissions the user had and what the UI showed, can be find in this table.

Note 1: Above, the "user needs to have m.room.join_rules" (or any other permission) means the user effectively having this permission - e.g. regardless if a PL is assigned to m.room.join_rules directly or it is inherited via the state_default.

Note 2: During the testing it was noted even though user was PL25 and both m.room.join_rules and m.room.canonical_alias were also PL25 but state_default was PL50, then the user could change room access, however the room address was not shown. Therefore it should be checked if that is a bug in the code, or there is a 3rd permission that is needed to make this section work.

[Velin92]

element-x-ios/ElementX/Sources/Services/Room/RoomPowerLevelProxyProtocol.swift

Lines 48 to 62 in 4f88715

	/// Can own user edit any of the security and privacy settings.
	func canOwnUserEditSecurityAndPrivacy(isSpace: Bool, joinRule: JoinRule?) -> Bool {
	let canOwnUserChangeAddress = switch joinRule {
	case .knockRestricted, .knock, .public:
	canOwnUser(sendStateEvent: .roomAliases)
	default:
	false
	}
	return if isSpace {
	canOwnUser(sendStateEvent: .roomJoinRules) || canOwnUserChangeAddress
	} else {
	canOwnUser(sendStateEvent: .roomEncryption) || canOwnUser(sendStateEvent: .roomJoinRules) || canOwnUser(sendStateEvent: .roomHistoryVisibility) || canOwnUserChangeAddress
	}
	}

This is the code that determines if the section is shown or not. (Alongside the room not being a DM)
So it may depend on join rule and being a space, but generally just being able to edit the join rule should be sufficient. All of these check are done directly from the SDK APIs... so maybe there is a limitation in how these values are computed from there?

[mxandreas]

This is the code that determines if the section is shown or not. (Alongside the room not being a DM)

Just deciding by the variable/function names, this is what I was expecting to see but there are a couple of things that does not make sense.

1. We're allowing the user into the section as soon as they have one of the permissions (as we seem to use the || operation). Technically, we could do that as well, but then we'd need to take care within the Security & privacy screen that user only sees those controls they have a permission for. If we do that already, that's fine. If not, it seems simpler to hide the complete section unless user has all of those permissions.

2. The fact that canOwnUserChangeAddress is false unless the current join rule (I assume joinRule is current join rule) is knock_restricted, knock or public looks strange. If the current join is private but you would change it to public and then wanted it to be published, you still needed permission to change address (and you may actually have it). Of course, given the current logic is the OR-logic, it does not effectively make a difference at this moment.

[mxandreas]

but then we'd need to take care within the Security & privacy screen that user only sees those controls they have a permission for. If we do that already

I tested with a room, and it seems like we do this already. However, I think there is probably a bug somewhere when it comes to assessing the effective permissions of the user.

Try the following cases with a user that is PL0.

When m.room.canonical_alias = 50; m.room.join_rules = unspecified, state_default = 0 then user are shown both the Access and Room address. However, changing room address of course fails, because the user actually is not allowed that.

When m.room.canonical_alias = 50; m.room.join_rules = 0, state_default = 50 then user are only shown the Access as expected.

[mxandreas]

@Velin92 But for spaces and/or iOS, it seems something else is wrong regardless what I said above. Because the Security & privacy section won't be visible when the user has m.room.join_rules and then it instantly becomes visible (together with Roles & permissions) if the user gets the m.room.power_levels. It does make me think that some mapping is wrong at the UI level.

Also, Android does not have that problem. As soon as the user gets the m.room.join_rules they can see the Security & privacy section (as well as changing the access works).

[mxandreas]

I went through the same scenarios now on Android, that I did yesterday with iOS. Everything worked as expected, no issues.

I was not also able to reproduce this Android.

When m.room.canonical_alias = 50; m.room.join_rules = unspecified, state_default = 0 then user are shown both the Access and Room address. However, changing room address of course fails, because the user actually is not allowed that.

When m.room.canonical_alias = 50; m.room.join_rules = 0, state_default = 50 then user are only shown the Access as expected.

[Velin92]

@Velin92 But for spaces and/or iOS, it seems something else is wrong regardless what I said above. Because the Security & privacy section won't be visible when the user has m.room.join_rules and then it instantly becomes visible (together with Roles & permissions) if the user gets the m.room.power_levels. It does make me think that some mapping is wrong at the UI level.

Also, Android does not have that problem. As soon as the user gets the m.room.join_rules they can see the Security & privacy section (as well as changing the access works).

Oh okay I think I understand the issue now... the SpaceSettings were still not using the new check I made for rooms to be more consistent with the UI, and still relying on permissions. Will fix it.

[mxandreas]

@Velin92 I tested the same scenarios again. It seems the Security & privacy is now visible exactly when the user has the permissions to edit join rules and/or canonical alias. However, saving of the settings fails. It says "Sorry, an error occurred". These are the permissions on the space:

{
    "users": {"@robotniiduk:beta.matrix.org": 25},
    "users_default": 0,
    "events": {
        "m.room.name": 50,
        "m.room.power_levels": 100,
        "m.room.history_visibility": 100,
        "m.room.canonical_alias": 25,
        "m.room.avatar": 50,
        "m.room.tombstone": 150,
        "m.room.server_acl": 100,
        "m.room.encryption": 100
    },
    "events_default": 100,
    "state_default": 25,
    "ban": 50,
    "kick": 50,
    "redact": 50,
    "invite": 50,
    "historical": 100
}

The @robotniiduk is the one trying to save the changes. Saving the changes works for the same user when using Android or when directly using API.

I think the issue is that it is trying to also update history_visibility which is of course irrelevant for spaces and should not be done. This is in the logs:

2025-12-22T15:11:38.737655Z ERROR elementx: Failed updating history visibility with error: MatrixApi(kind: MatrixRustSDK.ErrorKind.forbidden, code: "M_FORBIDDEN", msg: "You don\'t have permission to post that to the room. user_level (25) < send_level (100)", details: Optional("Error { status_code: 403, body: Standard(StandardErrorBody { kind: Forbidden { authenticate: None }, message: \"You don\'t have permission to post that to the room. user_level (25) < send_level (100)\" }) }")) | JoinedRoomProxy.swift:486 | spans: root

I also sent a complete rageshake.