Nextcloud Talk User/Group Management #1892
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
… notifications Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
… dark theme Actual fix is adjusting the regex on the server, allowing commas in the first regex: nextcloud/server#13650 Signed-off-by: Joas Schilling <coding@schilljs.com>
[stable15] Dark theme fixes
The browser history should not be modified from the Connection object, as this would mess with the history when Talk is embedded in other apps. Instead it is now modified only from the main Application object when the main Talk UI is being used. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Whenever a room was joined a new state for that room was pushed to the browser history. As this was always done even going back in the history caused a new state to be pushed to the history which, in turn, caused the previous state to be erased from the history. Due to this it was not possible to move back and forward between the rooms in the browser history. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When leaving the current room the main Talk URL ws pushed to the browser history. However, this kept the URL to the no longer accessible room in the browser history; in that case going back in the history failed and caused the whole app to reload. Now the main Talk URL replaces the room URL so going back in the history works as expected. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Joachim Bauch <bauch@struktur.de>
[stable15] Fix browser history
[stable15] Add hook to allow returning additional data for clients joining a room.
Signed-off-by: Joas Schilling <coding@schilljs.com>
Add changelog for 5.0.1
Signed-off-by: Joas Schilling <coding@schilljs.com>
The default Content Security Policy restricts connections only to the same domain of the page, so the domains of the web sockets used to connect to the standalone signaling servers must be explicitly allowed. This has to be done for Nextcloud as a whole, as Talk is embedded in other apps by loading additional scripts in the browser, and thus it is not possible to set the Content Security Policy in the controllers that serve those apps. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Joas Schilling <coding@schilljs.com>
[stable15] Add global Content Security Policy for signaling servers
[stable15] Always use white icons on the avatar-alike-placeholders
Signed-off-by: Joas Schilling <coding@schilljs.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
[stable15] Make sure there is always a trailing slash
[stable15] Fix page title not updated when room name is updated
SimpleWebRTC expects that screen offers from remote peers include the "broadcaster" property set to the ID of the peer; this is used to set the "sharemyscreen" property, which is used to differentiate Peer objects for sent and received screens. Screen offers received from the MCU do not include the "broadcaster" property, so SimpleWebRTC mark the Peer objects created from those offers as local screens. This causes, for example, that the remote screen peers are ended when the local screen is stopped. Due to this, now the "broadcaster" property is added to the screen offers received from the MCU before they are processed by SimpleWebRTC. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
…aring-own-screen-when-other-peer-is-sharing-the-screen [stable15] Fix sharing own screen when other peer is sharing the screen
When the virtual list is hidden adding new elements to it has no effect; it is necessary to explicitly reload it once visible for the new elements to be loaded. During a call the chat is moved to a tab in the sidebar, and when a different tab is selected the previous one is detached (and, thus, hidden). Therefore, when the chat tab is shown again the message list must be reloaded to load the messages that could have been added while hidden. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
[stable15] Fix message list not reloaded after being shown again
Signed-off-by: Joas Schilling <coding@schilljs.com>
Changelog 5.0.4
|
Please open an issue instead, pull requests are meant to contribute code :-) Also please check if there are already issues for them before opening new ones (as, for example, there is already one for circles integration). Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
I am looking for the possibility to have a better User and Options Management for the Talk App.
For Example: