Skip to content
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

multi user does not work after last update #1510

Open
1 task done
dePaauw opened this issue Feb 21, 2024 · 2 comments
Open
1 task done

multi user does not work after last update #1510

dePaauw opened this issue Feb 21, 2024 · 2 comments
Labels
confirmed-bug Issues with confirmed bugs

Comments

@dePaauw
Copy link

dePaauw commented Feb 21, 2024

This issue is unique.

  • I have used the search tool and did not find an issue describing my bug.

Operating System

Linux (RPM package)

Version information

8.0.0

Expected Behavior

We have been using DesktopEditors for over a year with no problems (snap package). Running on a Oracle Linus server, users use the DesktopEditors connecting to te server with RDP in their own workspace

Actual Behavior

Since the last update multi user doeas not work anymore. The first instance works fine but when a second user starts the program nothing seems to happen. Wat does happen is that the first user get a new tab, representing the second user.

Reproduction Steps

  1. start DesktopEditors on a client
  2. start DesktopEditors on a second client (nothing seems to happen)
  3. look at the first client to see the new tab

Additional information

No response

@nvkv
Copy link

nvkv commented Feb 27, 2024

I can confirm this behavior on Fedora Silverblue 39. Interestingly, the Flatpak version exhibited similar behavior, but I have switched to RPM version without further debugging.

However, the RPM version behaves identically. If User A is running onlyoffice-desktopeditors, User B cannot run it simultaneously. Another funnly observation is that if User B attempts to run OnlyOffice in their session, it either brings User A's desktop editors into focus or at least signals the intention to gain focus by shaking the GNOME dock icon.

@matveevms
Copy link
Member

Hello, @dePaauw
I can confirm - this is bug, I created issue #66636.
Thank you for the report.

@Rita-Bubnova Rita-Bubnova added the confirmed-bug Issues with confirmed bugs label Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed-bug Issues with confirmed bugs
Projects
None yet
Development

No branches or pull requests

4 participants