teams-for-linux
teams-for-linux copied to clipboard
IsmaelMartinez
away after a couple minutes
Teams shows away status after a couple minutes when using the computer, but not teams. This might only be happening on wayland and also happens in chromium.
In chromium I'm using a userscript as a workaround:
setInterval(() => {unsafeWindow.angular.element(document.body).injector().get('presenceService').setMyStatus(1, null, true); }, 15000)
But, could you clarify this
when using the computer, but not teams
Using other windows, moving mouse etc, but not having teams in focus
I guess the same script can be implemented here as well. Thanks.
Hm, the script forces online state all the time. Maybe something else can be done or this could be an option like --force-available
Since the chrome browser behaves the same, I'm tagging this as enhancement.
Using other windows, moving mouse etc, but not having teams in focus
Maybe powerMonitor.getSystemIdleTime() could be helpful.
https://www.electronjs.org/docs/latest/api/power-monitor#powermonitorgetsystemidletime
@sdirkwinkel How does your Script exactly work? I can't find any information about presenceService.
@sdirkwinkel How does your Script exactly work? I can't find any information about presenceService.
I haven't checked that but it must be there. Or try this one injector().get('appStateService').setActive()
@sdirkwinkel How does your Script exactly work? I can't find any information about presenceService.
Sorry for not seeing this earlier. Doing angular.element(document.body).injector().get('presenceService').setMyStatus(1, null, true); calls the teams function to set your online state. The rest is just about how to do it on a timer in the userscript.
There aren't really any docs on that since the presenceService is part of ms teams code.
you can probably modify the app to allow that sort of script to run on a timer.
Similar to this but might require a bit more logic (magic)
https://github.com/IsmaelMartinez/teams-for-linux/blob/develop/app/mainAppWindow/index.js#L95
I've tried to add the powerMonitor control but my electron-fu is near to zero, but at least there are the possible Presence Status values.
0 = "offline", 1 = "online", 2 = "busy", 3 = "away", 4 = "idle", 5 = "on-the-phone", 6 = "do-not-disturb", 7 = "be-right-back", 8 = "hidden", 9 = "disabled", 10 = "unknown", 11 = "appear-away", 12 = "reset", 13 = "out-of-office", 14 = "presenting", 15 = "busy", 16 = "on-shift", 17 = "off-shift", 18 = "focusing", 19 = "blocked", 20 = "appear-offline",
According to https://learn.microsoft.com/en-us/microsoftteams/presence-admins you can only use the subset: Available (online), Busy, Do not disturb, Away, Be right back, Appear offline.
just a quick fyi: lack of this functionality is currently prohibitive, as teams will not emit notifications when your status is "away". this means that notifications are not shown until you manually check this client, which makes them completely useless.
another workaround i've found is that other clients can override your status, so if you have another client open that doesn't have this issue that sets your status as "online", the teams-for-linux client will show the notifications as expected.
I am also showing an interest in this issue-I fought hard to be allowed to use linux as a work computer, and now constantly showing as away on teams is not a good look :(
Using pop-os 22.04, with x11. Is there a way to make a work around similar to OPs for x?
@31337-4554551n if you need an immediate workaround for that issue, the (now unmaintained/abandoned) official client can still be downloaded from the web archive. It works decently, albeit not quite as snappy as teams-for-linux, and it still uses an older interface. At the very least, it does not have this status issue and correctly keeps your status as "Online" as long as you are using your computer.
Arch Linux (or derivative distro) users can still use the teams AUR package based on the above deb installer.
Personally, I'm using this running in conjunction with the new client to workaround the status issue while still being able to use the newer client. As much as I hate running 2 separate instances of teams, it beats missing notifications (running only teams-for-linux) or having the meeting shared screen obstructed (only running the abandoned one).
This is (for me at least) the only issue with this client that prevents me from solely relying on it.
(and I've got a feeling many of the notification-related issues currently open may be affected by this, due to the notification muting behavior when "away")
As such, I've opened the following bounty on it to hopefully provide some incentive for prioritizing this: https://app.bountysource.com/issues/119136878-away-after-a-couple-minutes
Desired for payout:
- Status should stay "Online" at least as long as the system is being interacted with
- If the timeout is manually implemented in the client, it should have an option to be disabled (rely on PWA's default behavior)
- User should still have the ability to override the status by setting it manually (i.e. "Away", "Busy", "Offline", etc) (If doing this requires reverting to the PWA's default behavior, that's fine, as long as it's doable)
Optional: If the timeout has to be manually implemented in the client, I would love to see the timeout value exposed as a configurable option (show away after X minutes). Not strictly necessary for the resolution of this bug, but I'll chip in extra if that is implemented with this.
@lectrode the only difficulty is to find whether the status 'away' or any other set by user manually. I'm yet to figure out. But this issue will be handled very soon.
@lectrode the only difficulty is to find whether the status 'away' or any other set by user manually. I'm yet to figure out. But this issue will be handled very soon.
This shouldn't matter to get the users the core fix of "don't auto set away status", should it?
Something in the client which would mimic a 1 pixel mouse move or some form of event would prevent it from setting auto away without interfering with any custom set statuses. If the screen is locked-it would set away as normal.
This is because a custom set status won't be overwritten by mimicing activity.
All we need to know the changed status.
- 'Away' is 3
- If 3 check if it's triggered from user action 'Interactive' or 'Inactive'.
- If not from user check if system idle crossed the preferred threshold set by the user
- If not crossed, prevent from being set to 3 other wise allow.
Sounds reasonable. I'll keep the bounty open in part so I learn how to handle those going forward (I've never created one before, only contributed to others, and want to know how it handles payouts), and in part as a "thank you" for this effort.
@lectrode @31337-4554551n @rodricels @ocelik94 @mstroecker @sdirkwinkel can you test 1.5.60 once published? If someone is using flatpak I can publish a test build in flathub as well.
flatpak test build:
flatpak install --user https://dl.flathub.org/build-repo/17355/com.github.IsmaelMartinez.teams_for_linux.flatpakref
Run it this way
flatpak run --log-session-bus com.github.IsmaelMartinez.teams_for_linux
We can catch any dbus errors as it tries to get the system idle time.
@jijojosephk thank you. i've been testing the official client, 1.0.58, and 1.0.60 all day to see what's changed behavior-wise.
Test details: I made a 2nd teams account to see what my status looks like from the other side, and also more easily test various ways of trying to contact my main account through this client (send message, call, schedule meeting, start meeting, etc). When switching between Teams for Linux (TfL) versions, the config would be wiped to ensure an accurate test.
Minutes stated below describe the duration of time that the client is minimized while the system is in use. Actual idle time not yet tested.
| Feature | Official 1.5.00.23861 | TfL 1.0.58 | TfL 1.0.60 |
|---|---|---|---|
| Status shown to self | Online as long as interacting with system | Away after 5min | Online for full duration of test |
| Status shown to others | Online as long as interacting with system | Away after 5min | Away after 20min |
| Notify on new message | Full duration of test | Up to 30 min | Up to 30 min |
One other thing I noticed when testing 1.0.58 and 1.0.60 were that "(Name of Person) started the meeting" notifications do not appear at all. They only appear in the official client. Normal chat notifications show up as expected, however, and that is not related to this status issue.
Unfortunately, while the hack did prolong your "Online" status as shown to others by about 15 minutes, still not ideal for real-world use yet. The status hack was good in theory. Looks like M$ has other stuff going on behind the scenes to prevent the PWA from being usable.
@lectrode thanks for the detailed test. To study the behaviour further, let's not set the status from code, also instead of logging in developer tools, we can log to terminal. When we try to see the logs from developer tools, application gets focus and our test scenarios may fail. Let's see.
Is this actually fixed in 1.0.60 ? My status is "away" all the time now ... even when setting "available" and then "reset status", it switches back to "away"
Is this actually fixed in 1.0.60 ? My status is "away" all the time now ... even when setting "available" and then "reset status", it switches back to "away"
Though it cannot be called a fix yet, it will not block setting any status by manual intervention. In a few minutes I'll release another build on 1.0.60. Can you try when it happens?
When setting manual status, it works ok. But then chosing "reset status" reverts back to away (while I'm obiously in the interface clicking on it). Even now: status is marked away, moving my mouse around in the window or clicking on teams, chat, calendar: status stays "away" ...
@liedekef can you check the latest build (pre-release)? version number is same. https://github.com/IsmaelMartinez/teams-for-linux/releases/tag/v1.0.60
Uodated (using "rpm --reinstall XXX.rpm"). Currently status is "green" (available), let's see what happens :-)