사용자가 플랫폼 간을 이동하고 discourse로 진입할 수 있도록 초대 링크를 사용해 왔습니다. 그러나 최신 discourse 업데이트와 함께 표시되기 시작한 새로운 프롬프트가 지연과 혼란을 유발하고 있습니다.
토픽 포스트로 리디렉션되는 초대 링크를 사용하는 사용자는 링크를 단 한 번만 사용할 수 있습니다. 이는 사용자가 해당 토픽 포스트를 방문할 때마다 링크를 사용하도록 기대하고 있는 상황에서 주요 문제가 됩니다. 사용자가 토픽을 재방문할 때마다 같은 초대 링크를 사용할 수 있어야 하며, 이 기능이 새로운 프롬프트로 인해 차단되는 것은 문제를 일으키고 있습니다.
또한 다른 기술적 문제들도 발생했습니다. 첫째, ‘초대 수락’ 버튼 클릭에 대한 응답이 최소 5초 이상 걸리며, 이후 사용자가 토픽으로 리디렉션되는 데도 시간이 소요됩니다. 둘째, 이 새로운 기능이 추가되면서 프롬프트가 로드되는 데 더 많은 시간이 걸립니다. 셋째, 이전에 초대 링크를 클릭하고 초대를 수락한 경우에도 링크를 클릭할 때마다 계속 확인을 요청합니다!
이 문제를 재현하려면 토픽 포스트로 사용자를 리디렉션하거나/또는 그룹에 추가하는 초대 링크를 생성하십시오. discourse 계정으로 로그인한 상태에서 리디렉션 링크를 클릭해 보십시오.
설정에서 이 프롬프트를 비활성화할 방법이 있을까요? 사용자 경험에 직접적인 영향을 미치므로 시급하고 중요한 사안입니다.
초대 링크를 의존하고 있지만 이 새로운 변경 사항에 대해 통지를 받지 못해 인지하지 못하고 있을 수 있는 다른 사용자들도 있을 수 있습니다. 이 변경 사항에 대한 알림이 없었기 때문입니다. 감사합니다!
여기에도 버그가 있으며, 우리의 사용 사례에서는 애초에 프롬프트가 필요하지 않으므로 이를 제거할 수 있는지, 혹은 관리자 설정에서 비활성화할 수 있는 옵션을 제공해 줄 수 있는지 질문드립니다.
해당 버그는 '초대 수락’을 두 번째로 클릭할 경우 페이지가 정지되고 어떤 메시지도 표시되지 않는다는 것입니다. 이는 전혀 도움이 되지 않습니다. 이전 컨텍스트를 사용하여 다시 해당 주제로 리디렉션되는 것을 사용자에게 차단합니다. 이는 매우 심각한 문제입니다. 문서에 초대 링크를 넣고 독자가 같은 링크를 반복적으로 사용하여 해당 주제로 리디렉션되기를 기대하는 경우, 초대 링크가 더 이상 작동하지 않습니다.
우리는 사용자가 주제를 읽을 수 있도록 먼저 비공개 카테고리에 추가해야 하므로 초대 링크를 사용합니다. 사용자가 다시 주제를 찾아야 하는 경우, 동일한 초대 링크를 사용할 수 있어야 합니다. 이 경우 사용자가 로그인되어 있다면 초대 자체가 해당 사용자를 위한 것이므로 자동으로 초대 수락을 처리해야 하며, 이전에 정상적으로 작동했었으므로 사용자를 의도된 주제 게시물로 리디렉션해야 합니다.
초대 링크는 이전에 완벽하게 작동했습니다. 이 문제에 대해 다시 한번 확인해 주시고, 관리자도 이 ‘초대 수락’ 프롬프트/버튼 메시지를 비활성화할 수 있는 옵션을 제공해 주시길 바랍니다. 감사합니다!
Firefox 콘솔에서는 오류가 보이지 않지만, Chrome으로 시도할 때 간헐적으로 이러한 오류가 발생합니다.
includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
PUT https://XXX/invites/show/XXX.json 502
XMLHttpRequest.send @ includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
send @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:495
ajax @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:471
y @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
O @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
f @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
submit @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926
B._run @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450
B._join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4449
B.join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4412
p @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
a @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2481
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:719
_triggerAction @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:532
click @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:531
trigger @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2235
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
trigger @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4230
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
a @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4234
discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940
SyntaxError: Unexpected token '<', "<html>
<h"... is not valid JSON
at Function.parse [as parseJSON] (<anonymous>)
at i (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940:167)
at discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926:699
at b (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4291:12)
at g (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4289:128)
at h (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4287:107)
at p.invoke (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4377:192)
at p.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4369:141)
at h.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4384:207)
at B._end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4448:9)
at B.end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4401:240)
at B._run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450:118)
at B.run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4410:13)
at d (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577:23)
at u.error (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948:44)
at l (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:200:118)
at Object.fireWith [as rejectWith] (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:201:698)
at E (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:483:468)
at XMLHttpRequest.<anonymous> (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:494:206)
저희 사용 사례에서는 해당 프롬프트 메시지가 도움이 되지 않습니다. 관리자가 이러한 프롬프트 없이 초대 링크를 생성할 수 있는 방법이 있을까요?
초대 링크는 강의에서 참가자들이 토론 포럼에 참여하도록 초대하는 데 사용됩니다. 저희가 초대 링크에 기대하는 기능은 단순히 사용자를 그룹에 추가하고, 사용자가 링크를 사용할 때마다 '초대 수락’을 클릭할 필요 없이 비공개 카테고리의 특정 토픽으로 리다이렉트하는 것입니다. 그리고 첫 번째 클릭 후 사용자는 동일한 초대 링크를 통해 해당 토픽으로 돌아올 수 있어야 합니다. 이 기능은 프롬프트 메시지가 갑자기 강제 적용되기 전까지는 완벽하게 잘 작동하고 있었습니다.
Hi @gassim, 이 문제에 대해 내부적으로 논의했습니다. 죄송하지만, 같은 사용자가 초대장을 여러 번 수락하여 북마크처럼 사용하는 동작은 의도하지 않은 것이었으며, 로그인한 사용자가 이미 초대장을 수락한 경우 “초대 수락” 버튼을 숨기도록 수정할 예정입니다. 대신 사용자가 이미 초대 링크를 사용했다는 메시지를 표시할 것입니다.
페이지를 열 때 초대장을 자동으로 수락하는 기능은 보안 문제였기 때문에, 대신 중간 페이지인 “초대 수락” 페이지를 사용하도록 변경했습니다.
사용자가 동일한 토픽에 계속 돌아와야 한다면, 해당 토픽을 북마크하도록 권장합니다. 또는 초대 링크를 넣은 내부 문서가 있다면, 편의를 위해 같은 위치에 토픽 링크를 추가하세요.
알겠습니다… 초대 링크 생성 시 프롬프트 메시지를 사용할지 여부를 선택할 수 있는 옵션이 관리자한테 주어지기를 희망했습니다(프롬프트 메시지를 사용하지 않을 경우 발생할 수 있는 문제에 대한 경고와 함께요). 프롬프트 메시지가 없으면 누구나 비공개 그룹/카테고리에 접근할 수 있다는 점은 알고 있습니다. 하지만 우리의 사용 사례에서는 문제가 되지 않습니다. 왜냐하면 이들은 ‘비밀’ 그룹/카테고리가 아니라, 특정 주제에 대한 토론을 위한 전용 공간으로 분리해 두기 위해 비공개로 설정된 것이기 때문입니다.
코스 참여자들에게 주제에 북마크를 달라고 요구하기는 쉽지 않습니다. 하지만 후자의 제안이 현재 유일한 선택지이며, 문제를 해결하기 위해 즉시 취할 수 있는 조치인 것 같습니다.
@gassim 님은 잘 작동하는 시스템을 갖추고 있는 것으로 보이므로, 여기서는 그 시스템에 최대한 가깝게 유지하면서 몇 가지 가이드라인을 제시하는 것이 가장 좋다고 생각합니다. 특정 범주에 대한 액세스를 제한하고 다른 곳에서의 노이즈를 줄이기 위해 그룹을 계속 사용하세요.
초대 시스템의 몇 가지 거친 부분을 정리하여 유지보수성과 가독성을 높이고자 합니다. 그 과정에서 이러한 유형의 문제에 부딪힐 것으로 예상됩니다. 이 경우, 초대 링크를 재사용 가능한 주제 링크로 사용하는 것을 피하는 것을 원칙으로 하고 있습니다.
이전 주제를 읽어본 결과, 다음과 같은 방식으로 처리하는 것이 가장 합리적이라고 생각합니다.
각 과정의 초대 링크를 해당 주제로 직접 연결되는 링크로 교체합니다.
해당 링크 근처에 일반 초대 링크를 포함합니다. “아직 계정이 없으신가요? 클릭하여 계정을 만들고 그룹에 가입하세요”
초대 링크가 더 일반적인 개요를 다루는 주제로 유도하도록 설정하고, 사용자에게 자신의 과정으로 돌아가 거기에서 과정별 주제에 가입하도록 안내합니다.
비공개로 유지되는 방은 과정 수강생들을 위한 것입니다. 기본적으로 우리는 이러한 방이 포럼의 나머지 활동(최신, 최고 인기 등)에 영향을 주지 않는 전용 공간이 되기를 원합니다. 과정 토론 포럼을 비공개 카테고리로 두는 이유는 그것이 '비밀’이라서가 아니라, 과정에 등록한 사람들만 주제와 토론을 볼 수 있고, 등록하지 않은 사람들은 사이트의 나머지 부분을 평소처럼 계속 사용할 수 있도록 하기 위해서입니다.
좋은 제안 감사합니다! 아직 사이드바에 대해 실험을 해보지 않았지만, 왜 아직 사이드바를 적극 권장하지 않는지에 대한 제 생각을 자유롭게 적어보겠습니다:
홈페이지에는 이미 두 개의 열이 표시됩니다: 한 열에는 카테고리, 다른 열에는 최신 게시물이 표시됩니다. 사이드바가 있으면 홈페이지에서 중복되는 것처럼 보입니다. (홈페이지에서 사이드바를 끄는 방법이 없나요?)
사이드바는 개인 메시지(Private Messages)에 지나치게 많은 주의를 기울이게 만드는 것 같고, 우리는 개인 메시지 사용을 크게 권장하지 않습니다.
이 기능이 불편함을 덜어줄 것이라는 생각과 달리, 비공개 카테고리에 참여하는 과정 수강생들에게 사이드바는 방해 요소로 작용할 것입니다. 왜냐하면 그들의 참여 동안 다른 카테고리가 표시되는 것을 원하지 않기 때문입니다. (특정 카테고리에서 사이드바를 비활성화하는 옵션이 없나요?)
관리자가 '그룹’별로 사이드바를 사용자 정의할 수 있는 옵션이 있다면, A그룹의 참여자는 A그룹에 관련된 내용을, B그룹은 B그룹에 관련된 내용을 볼 수 있게 되어 불편함이 완화될 것입니다. 그 이유는 모든 사용자가 사이트를 자신의 이메일 계정처럼 대하고 사용자 정의를 배우는 데 시간을 보내기를 기대하지 않기 때문입니다. 반대로, 우리는 그들이 이미 편안함을 느끼고 사용자 정의를 배우는 데 시간을 들이지 않아도 바로 혜택을 누릴 수 있도록 맞이해야 합니다. 따라서 각 그룹별로 미리 사용자 정의해 두고, 그 후 사용자가 변경할 수 있는 선택지를 주는 것이 좋겠습니다. (게다가 홈페이지에서는 표시하지 않는 옵션도 필요합니다 - 기본적으로는 홈페이지에서 숨겨져 있어야 하며, 아마 CSS 코드로 해결할 수 있겠지만 그렇다면 특정 카테고리는 어떻게 해야 할까요?)
모든 과정에 등록하는 참여자를 위한 주제가 최소 50개 이상 있을 것이므로 확신할 수 없습니다. 하지만 우리는 @martin님의 제안을 사용하고 있습니다:
좋은 제안 감사합니다 @Stephen! 하지만 홈페이지는 모든 멤버를 위한 것이므로 변경하고 싶지 않습니다. 과정 수강생들은 여러 과정에 참여하지만, 각 과정이 끝나면 커뮤니티에서 계속 참여하도록 초대받습니다.
이해했습니다. 하지만 원래 관리자 옵션으로 초대 링크가 특정 횟수 사용 후나 특정 날짜 이후에 만료되도록 설정할 수 있었습니다(또한 특정 이메일 주소로 제한하는 것도 가능했죠). 저희는 초대 링크가 만료되지 않기를 원했기 때문에 만료 날짜는 2092년으로, 사용 횟수는 1,000,000회로 설정했습니다(물론, 사적 카테고리에서 토론 주제에 실제로 참여하고자 하는 누구나 참여할 수 있도록 하기를 원했기 때문에 이메일 주소 목록은 지정하지 않았습니다!). 하지만 이제 각 개별 사용자에게 첫 번째 사용 후 링크가 어차피 만료되므로, 이러한 옵션들이 얼마나 유용할지 모르겠습니다.
개인적으로는, 초대 링크 생성 시 위의 제약과 유사한 옵션을 추가하여 이 문제를 다르게 적용했다면 모든 것이 훨씬 쉬웠을 것이라고 여전히 생각합니다(기본적으로 초대 링크는 재사용 불가이며, 관리자가 이 옵션을 해제하면 discourse 팀이 우려하는 보안 문제에 대한 경고가 표시됩니다).
