2 posts were merged into an existing topic: Rename “private topics” to “personal message topics”
Short term memory loss. I had seen this earlier. ![]()
Was wondering though, will this way of filtering topics from all topic lists cause any performance issues?
I have not heard any complaints so far. The plugin has been written with performance in mind.
If a post in the private topic is marked as solved, then that post appears in the solved tab of the post owner’s profile and is visible to all.
Thank you for reporting this. We’re going to address this ASAP.
The issue reported by @SubStrider has been addressed. Please update to version 1.5.12 of the plugin.
Thank you again for reporting this @SubStrider ![]()
I stumbled over something I’d call a bug. It might not be a traditional issue in the code, maybe more a usability bug in the design. Still it caused some issues I’d like to prevent in future. Following context:
Discourse instance with three-digit number of users, used as a mailing list replacement. About 40 categories (= mailing lists) with a corresponding group for membership management. Some of the categories use the private topics plugin to mimic a mailing list where non members (but members of other lists) can write to. So far so good.
The issue:
Today the admin user wrote a topic in some of the lists to check-in with the list members about some settings. Everything fine for “normal”/closed categories where only the members of the corresponding group received the message. It did not work well for the categories using the private topics plugin. <edit> There, all hundreds of users, independently if they were members of that specific category/group or not, did receive an email with the message. There, all hundreds of users, all being members of the category as category rights were given to ![]()
everyone[1] but independently if they were members of the specific group defined in the category plugin settings to have visible rights or not, did receive an email with the message.
As recognized later, the website plugin setting Private topics permitted groups was still using the default Admin group. </edit>
(BTW we had this issue before, where a user, being an admin plus having their “normal” account, did send out (mistakenly by the email address associated with the admin user and no not normal user) an internal document to a category using the private topics plugin, resulting in information leakage. At that time I didn’t connect the dots to this plugin, only today it became clear to me what had happened at that time)
Expected behavior:
I can see the reasoning behind the design choice, that posts/emails of admins are always visible/sent by mail. But in this case the intention was to only inform the members of the category/group. That some hundred emails were sent out to everybody in this discourse instance was very intransparent (and unpleasant) to me.
Possible fix:
I’d wish to improve this situation. As mailin is available as well, a simple confirmation dialog will not work. Maybe this could be a global setting in the plugin or per category using the plugin, to either handle admin posts as visible to everybody or as visible to only category/group members? That would at least raise awareness during setting up a new category.
which should not be used, but
trust_level_0should be used, see OP ↩︎
Can you please send me a PM with all the information you can think of that is relevant, including:
-
the versions of Discourse and the plugin
-
the plugin settings
-
other plugins you have installed
-
the category security settings and the category-specific plugin settings for an affected category
-
the notification settings
-
is mailing list mode enabled?
-
whether those users that inadvertedly received the email notification, are also able to see the topic when they visit the category
-
anything else that might matter in helping us reproduce
Thanks for your fast reply!
Done. And the questions helped me to find the root cause (website settings: plugin settings: Private topics permitted groups). So code-wise works as designed, IMHO a UX issue that would benefit from some improvement. ![]()
One of the things that were counterintuitive is that the private topics do not work correctly when access is granted to ‘everyone’. This is mentioned in the OP but to be honest I have fallen for this myself more than once. I have added a warning in the settings that shows when private topics are enabled in a category that is accessible for ‘everyone’.
Thanks again to @RGJ to take the time to debug and think trough the issue with me, helping me to spot my configuration error in using the everyone group. As in my installation only logged in users have access to discourse contents, I initially failed to understand the difference between everyone and trust_level_0 – but now learned, that Discourse handles these quite differently. So no issue with the plugin, and even more thankful for the added warning, as I fear, I would have fallend in that trap sooner or later again… ![]()
사용자가 개별 주제를 사적으로 생성할 수 있는 버튼을 제공하는 것이 가능할까요? 저희는 대학 강의에서 이 기능을 사용하고 있으며, 기본적으로 학생들의 게시글이 공개되도록 하되, 게시 시 사적으로 설정할 수 있는 옵션을 제공하길 원합니다.
게시물 5개가 기존 주제에 병합되었습니다: 주제를 "좋아요"하기 전까지 카테고리 내 게시 제한
프로세스에 대해 더 자세한 정보를 제공해 주실 수 있을까요?
- 학생이 게시물을 올릴 때, 공개/비공개 여부를 스스로 선택할 수 있기를 원하나요?
x시간이 지난 후에도 토픽의 공개 범위를 재설정할 수 있어야 하나요?
간단한 우회책으로는 토픽을 DM으로 전환하거나, 그 반대로 전환하는 것입니다. 그룹으로 전송하는 것도 가능합니다.
이 경우, DM에서 공개로 전환하거나 토픽에서 비공개로 전환하려면 관리자 개입이 필요합니다.
@RGJ 이 게시물을 원래 위치로 옮겨주세요. 여기에 올린 것이 아닙니다.
완료했습니다. 제 실수였습니다. 다른 게시물들과 함께 이동하는 것은 아니어야 했습니다.
다만, 이 특정 사용 사례에 대한 추가 논의도 이곳에 적합하지 않다고 생각합니다. 토론은 Private Topics 플러그인에 집중해 주시기 바랍니다.
이 플러그인에 대해 콘솔에서 비권장(deprecation) 경고가 표시됩니다:
deprecation-identify-source.js:15 DEPRECATION: [PLUGIN discourse-private-topics] `@ember/service`에서 `inject`를 가져오는 것은 비권장됩니다. 대신 `service`를 가져오세요. [deprecation id: importing-inject-from-ember-service] 이 기능은 ember-source 7.0.0에서 제거될 예정입니다. 자세한 내용은 https://deprecations.emberjs.com/id/importing-inject-from-ember-service 를 참고하세요.
수정 사항을 push했습니다(경고 자체는 무해했지만요). 보고해 주셔서 감사합니다.
전체 검색을 사용하여 키워드를 검색할 경우, 개인 지원 스레드에 접근할 수는 없지만 미리보기가 표시됩니다.
