Skip to content

ffi: Fix get_element_call_required_permissions #3455

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

Merged
merged 1 commit into from
May 24, 2024

Conversation

stefanceriu
Copy link
Member

-fix what permissions get_element_call_required_permissions returns and have them match what Element Call actually expects

  • this got implemented in Add get_element_call_required_permissions #2825 but never actually worked in the app, resulting in ElementCall getting stuck on a Loading screen
  • tweaked the permissions list by running ElementCall and comparing it to the capabilities returned in acquireCapabilities(capabilities:)
  • check all of this with @toger5, which also tells me that org.matrix.msc3401.call is deprecated and should not be required although ElementCall doesn't work without it. He will clean up the web side and then come back to remove this as well in a later PR.

…urns and have them match what Element Call actually expects
@stefanceriu stefanceriu requested a review from a team as a code owner May 23, 2024 15:23
@stefanceriu stefanceriu requested review from bnjbvr and toger5 and removed request for a team May 23, 2024 15:23
@bnjbvr bnjbvr changed the title Fix get_element_call_required_permissions ffi: Fix get_element_call_required_permissions May 23, 2024
Copy link
Member

@bnjbvr bnjbvr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can we test this, other than running it on the apps? This seems quite frail; it would make sense in my opinion to take all the ElementCall related call, put it under a new crate umbrella so we can test it properly, and then expose that to the FFI, maybe?

(Note: the above questions are general discussions to have for a better strategy for all of this, and don't block the merging of this PR if Timo says it's fine to merge as is.)

Copy link

codecov bot commented May 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.27%. Comparing base (7fb57ea) to head (627b983).
Report is 9 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3455      +/-   ##
==========================================
- Coverage   83.27%   83.27%   -0.01%     
==========================================
  Files         247      247              
  Lines       25091    25091              
==========================================
- Hits        20895    20894       -1     
- Misses       4196     4197       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@stefanceriu
Copy link
Member Author

How can we test this, other than running it on the apps?

I'm not entirely sure to be honest as in the end you need to run the actual ElementCall web app to validate things actually work. I reckon an integration UI test in the final client would be the simplest way.

@toger5
Copy link
Contributor

toger5 commented May 23, 2024

I think this particular case is very much a Element Call testing case and not rust sdk.
The original implementation is technically the more correct one it leaves out a capability which is not needed by element call in theory but element call apparently also does not laod when it is missing.
So this is very much a stop gap until we find the issue on ElementCall. Which we still should merge since it is a security related issue/change.

The best test approach imo is to strictly define the permissions we want the widget to have and then use test that both projects are compatible with our defined capabilities.
We would need a test in element call that it successfully loads with the correct capabilities. (The rust sdk just needs a unit test that it only allows the defined capabilites.)

Going forward we need to eventually use resources on the voip team to investigate why ElementCall wont load if the capability is missing. then we can remove the org.matrix.msc3401.call part of the pr again.

@stefanceriu
Copy link
Member Author

Alrighty, I think you can go ahead and merge this @bnjbvr. Thaaank you!

@bnjbvr bnjbvr merged commit 03069f7 into main May 24, 2024
38 checks passed
@bnjbvr bnjbvr deleted the stefan/elementCallWidgetPermissions branch May 24, 2024 08:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants