-
Notifications
You must be signed in to change notification settings - Fork 265
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
feat(room): add methods to customise a Room's privacy settings #4401
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4401 +/- ##
==========================================
- Coverage 85.36% 85.34% -0.02%
==========================================
Files 284 285 +1
Lines 31887 31962 +75
==========================================
+ Hits 27221 27279 +58
- Misses 4666 4683 +17 ☔ View full report in Codecov by Sentry. |
15d2db1
to
736f2c0
Compare
@@ -1152,17 +1152,6 @@ impl Client { | |||
let alias = RoomAliasId::parse(alias)?; | |||
self.inner.is_room_alias_available(&alias).await.map_err(Into::into) | |||
} | |||
|
|||
/// Creates a new room alias associated with the provided room id. | |||
pub async fn create_room_alias( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was just moved to a different file, to have the functions grouped.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, I left a couple of recommendations but nothing major.
@@ -155,6 +155,12 @@ impl From<RoomSendQueueError> for ClientError { | |||
} | |||
} | |||
|
|||
impl From<NotYetImplemented> for ClientError { | |||
fn from(_: NotYetImplemented) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're starting to use that more and more, I wonder if NotYetImplemented
should contain more information, i.e. so we know which exact feature isn't yet implemented. (if you agree, this can be part of a separate PR)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, but as you suggest I'd rather make this change in a new PR.
/// Update the canonical alias of the room. | ||
/// | ||
/// Note that publishing the alias in the room directory is done separately. | ||
pub async fn update_canonical_alias(&self, new_alias: Option<OwnedRoomAliasId>) -> Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should explain what providing a None
does. An example wouldn't hurt either.
|
||
use crate::{Error, Result, Room}; | ||
|
||
impl Room { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is already in a separate module and adds a lot of functionality, I think it makes sense to introduce a "fake" struct for this that groups all the privacy settings under its umbrella.
pub struct RoomPrivacySettings<'a> {
room: &'a Room
}
impl RoomPrivacySettings {
...
}
That way you would call:
room.privacy_settings().update_canonical_alias(my_alias).await?
Take a look at the Encryption
struct and module, we do the same thing there to avoid cluttering the Client
object with a lot of E2EE related methods.
Ok(()) | ||
} | ||
|
||
/// Update room history visibility for this room. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs on all these methods are a bit terse, it might be nice to explain briefly what the history visibility is and link to the spec for more info.
This applies to the other methods as well, an example here and there wouldn't hurt either.
/// use matrix_sdk::{ | ||
/// ruma::room_alias_id, test_utils::mocks::MatrixMockServer, | ||
/// }; | ||
/// use ruma::api::client::room::Visibility; | ||
/// | ||
/// let mock_server = MatrixMockServer::new().await; | ||
/// let client = mock_server.client_builder().build().await; | ||
/// | ||
/// mock_server | ||
/// .mock_room_directory_remove_room_alias() | ||
/// .ok() | ||
/// .mock_once() | ||
/// .mount() | ||
/// .await; | ||
/// | ||
/// client | ||
/// .remove_room_alias(room_alias_id!("#a:b.c")) | ||
/// .await | ||
/// .expect("We should be able to remove the room alias"); | ||
/// # anyhow::Ok(()) }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a bunch for adding examples on these.
It turns out this needs further work, so I'll upload some more changes tomorrow with both the needed changes and some logic changed too to take into account the public room visibility and being able to retry the whole 'publish and update alias' flow if the alias was published but the process got interrupted before. |
This can be accessed through `fn Room::privacy_settings` and will wrap the functionality related to a room's access and privacy settings. This commit includes the `fn RoomPrivacySettings::update_canonical_alias` to modify the canonical alias of a room.
…irectory`. This also needs some new mocks for resolving room aliases.
736f2c0
to
6774747
Compare
Sorry for the force push @poljar, but the code had so many changes I couldn't find a good way to make them easy to review in little steps, so in the end I just reset my commits and split the code again in smaller chunks. |
Hah, you're in luck, I forgot almost everything about the review anyways 😅. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, I left two final nits but then we're good to go.
Visibility::Public => Self::Public, | ||
Visibility::Private => Self::Private, | ||
Visibility::_Custom(_) => Self::Custom { value: value.to_string() }, | ||
_ => panic!("This visibility mapping branch should never be reached"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless Visibility
gets another variant. Can't we do value.as_str()
and convert it into the custom variant instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -509,19 +511,109 @@ impl MatrixMockServer { | |||
} | |||
|
|||
/// Create a prebuilt mock for resolving room aliases. | |||
/// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ey, thanks for adding examples to these.
// Give some time for the sync to run | ||
tokio::time::sleep(tokio::time::Duration::from_secs(2)).await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will be flaky, and if the sync isn't slow it it slows down the test unnecessarily. Can't we listen for the event to arrive using an event handler and use the timeout method to make sure that we're not blocking forever if the event never arrives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
c372fcb: I tried using Mutex but I couldn't get it to work, so I followed a different example which used channels and it worked fine. I wouldn't mind learning how this should be done with Mutexes though 😅 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Err, I don't think you can do so using a mutex, you need something that's a future that resolves once you receive the event. I think a channel is perfect for this, or perhaps a shared observable could work as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks.
These include:
Also, expose the room history visibility through the FFI RoomInfo.
Signed-off-by: