لقد وجدت خطأً كبيرًا (أعتقد) في دردشة Staff . عندما تتم إزالة مستخدم من فريق العمل، لا تتم إزالته من دردشة فريق العمل. ما لم تكن هناك طريقة لإزالته لا أعرفها؟ يبدو أن هذا يجب أن يكون تلقائيًا.
9 إعجابات
j.jaffeux
(Joffrey Jaffeux)
15 يوليو 2022، 4:42م
3
سأتعامل مع هذا لاحقًا اليوم شكرًا
8 إعجابات
j.jaffeux
(Joffrey Jaffeux)
15 يوليو 2022، 7:14م
5
لقد قمنا بعمل مهمة مؤجلة (TODO) لهذا داخليًا، ولن يتم إصلاح هذا قبل الأسبوع المقبل بالتأكيد. سيكون هذا أحد أولوياتي للأسبوع المقبل، أعتذر عن ذلك.
7 إعجابات
mcwumbly
(Dave McClure)
20 يوليو 2022، 5:49م
6
أحد الأشياء التي أريد توضيحها هو أنه على الرغم من أن هؤلاء المستخدمين لا يزالون مدرجين كأعضاء في القناة، فإن المستخدمين الذين تمت إزالتهم من الموظفين أو أي مجموعة أخرى لا يمكنهم رؤية القنوات التي فقدوا الوصول إليها، ولا يمكنهم رؤية أو إرسال رسائل داخل تلك القنوات.
لا يزال الأمر مضللاً، ولدينا هذا على رأس قائمتنا.
سنصل إليه قريبًا، ونخطط لأخذ الوقت اللازم لفرز الحالات المختلفة التي قد توجد حيث قد يحتاج وصول المستخدمين وعضويتهم في القنوات إلى الإزالة.
9 إعجابات
sam
(Sam Saffron)
30 أكتوبر 2025، 1:43ص
7
لقد سقط هذا بين الشقوق، لكنني لست متأكدًا بصراحة من الحل المعقول.
يمكننا “ضمان الاتساق” وتشغيل وظيفة بين الحين والآخر تزيل الأشخاص الذين ليس لديهم وصول.
يمكننا “إخفاء المعلومات” وعدم عرض المستخدمين الذين ليس لديهم وصول والذين هم بطريقة ما في قناة.
قبل أن نفعل أي شيء هنا، يجب أن نقرر ما هو السلوك المطلوب لدينا.
mcwumbly
(Dave McClure)
30 أكتوبر 2025، 1:58ص
8
انتظر… لم أعد إلى هنا أبدًا، ولكن هذه بعض التغييرات ذات الصلة التي تم دمجها بخصوص هذا الأمر:
main ← feature/remove-users-without-permission-from-channel
opened 04:06AM - 17 Feb 23 UTC
There are many situations that may cause users to lose permission to
send messa… ges in a chat channel. Until now we have relied on security
checks in `Chat::ChatChannelFetcher` to remove channels which the
user may have a `UserChatChannelMembership` record for but which
they do not have access to.
This commit takes a more proactive approach. Now any of these following
`DiscourseEvent` triggers may cause `UserChatChannelMembership`
records to be deleted:
* `category_updated` - Permissions of the category changed
(i.e. CategoryGroup records changed)
* `user_removed_from_group` - Means the user may not be able to access the
channel based on `GroupUser` or also `chat_allowed_groups`
* `site_setting_changed` - The `chat_allowed_groups` was updated, some
users may no longer be in groups that can access chat.
* `group_destroyed` - Means the user may not be able to access the
channel based on `GroupUser` or also `chat_allowed_groups`
All of these are handled in a distinct service run in a background
job. Users removed are logged via `StaffActionLog` and then we
publish messages on a per-channel basis to users who had their
memberships deleted.
When the user has a channel they are kicked from open, we show
this dialog.
<img src="https://user-images.githubusercontent.com/920448/221748981-248e6d89-1b81-454d-9744-b0d0e68a6c2e.png" width="400">
When they click OK we redirect them either:
* To their first other public channel, if they have any followed
* The chat browse page if they don't
This is to save on tons of requests from kicked out users getting messages
from other channels.
When the user does not have the kicked channel open, we can just
silently yoink it out of their sidebar and turn off subscriptions.
main ← perf-chat-auto-join-take-42
opened 04:35PM - 14 Oct 24 UTC
Chat channels that are linked to a category can be set to automatically join use… rs.
This is handled by subscribing to the following events
- group_destroyed
- user_seen
- user_confirmed_email
- user_added_to_group
- user_removed_from_group
- category_updated
- site_setting_changed (for `chat_allowed_groups`)
As well as a
- hourly background job (`AutoJoinUsers`)
- `CreateCategoryChannel` service
- `UpdateChannel` service
There was however two issues with the current implementation
1. We were triggering a lot of background jobs, mostly because it was decided to batch to auto join/leave into groups of 1000 users, adding a lot of stress to the system
2. We had one "class" (a service or a background job) per "event" and all of them had slightly different ways to select users to join/leave, making it hard to keep everything in sync
This PR "simply" adds two new services. `AutoJoinChannels` and `AutoLeaveChannels` that takes care, in an efficient way, of all the cases when users might automatically join and leave a chat channel.
Every other changes come from the fact that we're now always calling either one of those services, depending on the event that happened.
In the making of these classes, a few bugs were encountered and fixed, notably
- The `chat_allowed_group` site setting was missing the (dynamic) `@staff` group
- A user is only ever able to access chat channels if and only if they're part of a group listed in the `chat_allowed_group` site setting
- A category that has no associated "category groups" is only accessible to staff members (and not "Everyone")
- A silenced user should not be able to automatically join channels
- We should not attempt to automatically join users to deleted chat channels
- There is no need to automatically join users to chat channels that have already more than `max_chat_auto_joined_users` users
Internal - t/135259 & t/70607
إعجاب واحد (1)
sam
(Sam Saffron)
30 أكتوبر 2025، 2:01ص
9
رائع، سأغلق هذا الآن، يمكننا إعادة فتح أخطاء جديدة إذا اكتشفنا حالات حافة جديدة بعد هذه التغييرات.
إعجاب واحد (1)