Skip to content

Initial state of federated room may not match the current state of the remote room #13060

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

Closed
danxuliu opened this issue Aug 21, 2024 · 0 comments · Fixed by #13072
Closed

Initial state of federated room may not match the current state of the remote room #13060

danxuliu opened this issue Aug 21, 2024 · 0 comments · Fixed by #13072

Comments

@danxuliu
Copy link
Member

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Once a participant has been invited the federated server will receive the relevant updates about the room state from the host server. However, when the federated room is created its initial state only reflects the current name and type. The room avatar will be correctly shown as well even if not set, as it is proxied from the host server (so it could be removed from the notified changes?).

How to reproduce (scenario 1)

  • Setup Nextcloud server A and B and enable Talk federation
  • In server A, create a conversation
  • Set the description
  • Add a federated user
  • In a tab or private window, log in server B
  • Accept the invitation
  • Join the conversation

Expected result

The description of the federated conversation matches the host conversation

Actual result

The description of the federated conversation does not match the host conversation

How to reproduce (scenario 2)

  • Setup Nextcloud server A and B and enable Talk federation
  • In server A, create a conversation
  • Set the conversation as read-only
  • Add a federated user
  • In a tab or private window, log in server B
  • Accept the invitation
  • Join the conversation

Expected result

The federated conversation is read-only

Actual result

The federated conversation is not read-only

How to reproduce (scenario 3)

  • Setup Nextcloud server A and B and enable Talk federation
  • In server A, create a conversation
  • Enable the lobby
  • Add a federated user
  • In a tab or private window, log in server B
  • Accept the invitation
  • Join the conversation

Expected result

The lobby is shown to the federated user

Actual result

The lobby is not shown to the federated user, but the user can not join the conversation

How to reproduce (scenario 4)

  • Setup Nextcloud server A and B and enable Talk federation
  • In server A, create a conversation
  • Start a call
  • Add a federated user
  • In a tab or private window, log in server B
  • Accept the invitation
  • Join the conversation

Expected result

The federated user sees that a call is in progress

Actual result

The federated user sees "Start call" instead of "Join call"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants