I initially thought that might be the cause, but some of the users in the list haven’t been active for a long time…possibly ever. I don’t have an exact number…but could do more digging on that, if needed.
Do you mean/guessing that ”add everyone” is actually ”add those how have been interacted in some time range”?
We do currently filter out users who are “inactive” (as well as “staged” users and anonymous users). Here are the specs for that logic.
@Roman_Rizzi, are there tests that cover the scenario for these users if they later become active? Or is that implied by the existing spec because this job is run periodically?
Good question. We only covered the user’s activation, so that’s a scenario I missed. The job doesn’t run periodically, but it probably should, as we keep finding more cases where the user’s state changes, and we need to auto-join them.
That definitely makes sense. Is the “inactive” status used here the same as the “Activated/Deactivated” flag in the admin dashboard or is it connected to something tracking actual ongoing usage of the platform? If it’s the former, we still have an issue because we only have two deactivated users, no staged users, and 13 anonymized users.
Active has two meanings here. It has to be active, as their email is confirmed, but it also means they visited the site at least once in the last three months (we check their
last_seen_at attribute for this).
Just as a heads-up…I did a quick check and found about 24 tl0 accounts just in the "A"s of our auto-added chat participants who have never logged in to the platform since their accounts were approved. Most of them created accounts in the 2018-2019 timeframe. They should have all been considered inactive, by that definition.
Yes, this was intentionally for handling the case where the user is created, but it doesn’t really make sense. Moving to a scheduled job will fix this too.
6 posts were merged into an existing topic: Automatically add user to channel based on group subscription
So if I have
chat allowed groups set to tl1 user and allow a channel to auto add users which linked to a tl0 accessible category, what will happen? Does this later option overwrite the former one?
It should respect both settings and only tl1 users will be added in this case.
Thx for the reply, I see the linked channel (which is linked to a tl0 accessible category) shows it has around 1700 members, but my tl0 users are around 4000 as shown on the group page, I have removed the tl1 restriction, but the number doesn’t increase. Is there a data delay or any settings will also affect this number?
Currently the users get added to the channel based on the category permissions, but those outside of the
chat allowed groups simply can’t see any chat features at all and so don’t have access. There are a couple of other criteria that go into whether they’re ‘active’ or not and get scooped up into being added, which may account for the difference in numbers:
I’m experiencing the same issue that @sdpiowa identified earlier in this thread:
I understand from this thread that only “active” users join the channel. That’s fine – though the label on the option should be updated to more accurately describe the feature.
What remains unclear to me is whether this check is run periodically. In other words, if a previously inactive user interacts with the site tomorrow will they automatically join the chat channel or not?
Any confirmation on my question above?
I guess by now you should have empirical evidence?
I can’t quite tell what
subject.execute(chat_channel_id: channel.id, starts_at: user.id, ends_at: user.id) does in the spec, but I think that those users are added continually.
On my forum returning users will be added continually. Sure, there can be somekind delay, but it can’t be long.
(That shows one metric I could guess quite many community admins dislike It tells directly how many pseudo users that community has…)
Yep, the job runs every hour and should cover this scenario.
Definitely open to suggestions to improve the copy here to make this part more clear!
Well, the current copy is “Automatically add all new and existing users”, which is clearly false.
How about “Automatically add users who [whatever the criteria are]”?
Here’s a first pass: