이메일이 비활성화되어 있어도 이메일 환경 설정이 계속 표시됩니다

모든 이메일이 비활성화될 때 UX 관점에서 몇 가지 이상한 일이 발생합니다.
이것들을 버그라고 규정하고 싶습니다.

  1. 스태프가 아닌 사용자까지 포함해 모든 사람이 시스템이 이메일을 보내지 않는다는 메시지를 받습니다. 이 알림을 끄는 방법이 없어 보입니다. 사용자가 이 알림을 계속 받는 데는 이유가 없어 보입니다. 스태프나 관리자만 표시하는 것이 적절할 수도 있습니다. 언젠가 의도적인 결정이었을 수도 있습니다. 다만 관련 논의는 찾지 못했습니다.

https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/components/global-notice.js#L99

   if (
        this.siteSettings.disable_emails === "yes" ||
        this.siteSettings.disable_emails === "non-staff"
      ) {
        notices.push(
          Notice.create({
            text: I18n.t("emails_are_disabled"), // "All outgoing email has been globally disabled by an administrator. No email notifications of any kind will be sent."
            id: "alert-emails-disabled",
          })
        );
      }

가드 조건을 다음과 같이 변경해야 한다고 생각합니다.

if (
        this.get("currentUser.staff") && // 또는 currentUser.admin
        (this.siteSettings.disable_emails === "yes" ||
        this.siteSettings.disable_emails === "non-staff") 
      ) {
          …

아니면 최소한 누가 이 알림을 받을지 결정할 수 있는 설정을 두는 것이 좋습니다. (예: 모든 사람/스태프/관리자/없음)

또한 FIX: Show 'emails disabled' to staff users when disabled for non-staf… · discourse/discourse@acc121f · GitHub 에서 이 수정 사항의 아이디어는 이메일 비활성화 알림을 스태프에게만 표시해야 한다는 것이었던 것 같습니다. 하지만 스펙 https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/tests/acceptance/email-notice-test.js#L24 은 모든 사람이 알림을 확인하는 것을 검증하고 있습니다.

부수적인 언급으로: test("when … 라는 표현이 조금 혼란스럽습니다. 예를 들어: When enabled 은 실제로 disable_emails = "yes" 를 테스트합니다. 설정 변경에 대한 테스트를 이해하지만, 실제로는 이메일 비활성화를 테스트하는 것이고, 반대로 When disabled 는 이메일 활성화 상태를 테스트합니다. 아마도 최종 효과보다는 설정된 값에 초점을 맞춘 것이 프로젝트의 관례일 것입니다. 그렇다면 전혀 문제가 되지 않습니다. 다만 신규 입장에서 보면 조금 낯설게 느껴질 뿐입니다.

  1. disable_emails 가 “yes” 또는 “non-staff” 로 설정되어 있든, 이메일 섹션은 모든 사용자의 사용자 설정 페이지에 여전히 표시됩니다. 이는 이상한데, 템플릿 내부에는 다이제스트나 메일링 리스트가 비활성화될 때 해당 부분을 비활성화하는 체크가 존재하기 때문입니다.

확인하실 수 있듯이, 여기에는 체크가 없습니다. https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/templates/preferences.hbs#L18

    <li class="nav-emails">
      {{#link-to "preferences.emails"}}
        {{i18n "user.preferences_nav.emails"}}
      {{/link-to}}
    </li>

제 버전에서는 다음과 같은 코드를 사용했습니다. (이것이 여러분이 하는 방식인지 모르겠습니다. 참고로) 제안 사항에 개방적입니다 :slight_smile:

      {{#if (show-emails-preferences model siteSettings.disable_emails)}}
          <li class="nav-emails">
            {{#link-to "preferences.emails"}}
              {{i18n "user.preferences_nav.emails"}}
            {{/link-to}}
          </li>
      {{/if}}

여기서 show-emails-preferences 는 다음과 같이 헬퍼에서 정의됩니다:

registerUnbound("show-emails-preferences", (model, disable_emails, args) => {
  let result = true;
  if(disable_emails === 'yes'){
    result = false;
  }else if(disable_emails === 'non-staff'){
    result = model.staff ? true : false;
  }else{
    result = true;
  }
    return result;
});

이 중 가치 있는 개선 사항이 있다면 알려주세요. PR을 만들 수 있습니다.

감사합니다

1개의 좋아요

전체 템플릿도
https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/templates/preferences/emails.hbs#L1
다음과 같이 감싸고 있다는 것을 언급하는 것을 잊었습니다.

  {{#if (show-emails-preferences model siteSettings.disable_emails)}}
    {{#unless siteSettings.disable_mailing_list_mode}}
…

Discourse는 이메일 없이는 작동할 수 없습니다.

계정을 등록하거나, 비밀번호를 재설정하거나, 알림을 받거나, 이메일로 로그인하는 것이 불가능합니다. 이메일은 필수적인 요소입니다. 그 배너가 표시되는 이유는 사이트가 고장 났다는 것을 모든 사용자에게 알리기 위해서입니다.

그 경고 메시지를 비활성화할 수 없다는 것은 버그가 아니라 기능입니다.

인증에 SSO만 사용하는 경우는 어떻게 되나요?
Discourse에는 이메일 로그인을 비활성화하고 SSO를 유일한 인증 시스템으로 허용하는 기능이 있습니다.
"로컬 로그인 활성화"와 "이메일을 통한 로컬 로그인 활성화"를 모두 false로 설정할 수 있습니다.
또한 "이메일 비활성화"를 "예"로 설정할 수도 있습니다.
아마도 단독 제품으로는 제대로 작동하지 않을 수 있지만, 더 큰 시스템의 일부로는 사용할 수 있습니다. 또한, 만약 "Discourse는 이메일 없이 작동할 수 없다"는 말이 사실이라면, 왜 시스템을 깨뜨리는 이러한 설정들이 모두 존재하는 것일까요?

“그 배너는 사이트가 깨져 있다는 것을 모든 사람에게 알리기 위해 있는 것입니다.”
다시 말하지만, "모든 사람"이 알아야 한다고 생각하지 않습니다.
적어도 제 생각에는, 제품 소비자가 아니라 스태프나 관리자만 알면 충분합니다.

참고로, 저희는 이렇게 사용하고 있습니다. 로그인/로그아웃/가입/비밀번호 재설정 등을 수행하는 메인 웹사이트가 있습니다.
Discourse에 접근하는 유일한 방법은 SSO를 통한 것입니다. 이렇게 하면 그룹을 통해 권한을 쉽게 프로비저닝할 수 있습니다.

1개의 좋아요

@pfaffman 별개의 이야기지만, 그 메서드에 대해 어떻게 생각하시나요?

이것이 적절한 수준/방법(discourse 방식에 대해 이야기하는 것)인가요?

코드를 충분히 탐색하고 엄격한 "discourse 방식"의 코딩 관행을 추출할 시간이 많이 없었습니다.

네, 뭔가 중요한 걸 짚은 것 같네요. 제가 SSO가 활성화되어 있으면서도 “이메일이 비활성화되었습니다” 배너가 표시되는 discourse 인스턴스를 실제로 발견했는데, 저는 로그인조차 되어 있지 않은 상태였습니다.

SSO를 사용하면 비밀번호 재설정 문제를 걱정할 필요가 없으므로, 사람들이 이메일 알림을 받지 못하는 점을 제외하고 SSO가 활성화되어 있을 때 이 배너를 모든 사람에게 표시해야 하는 이유가 무엇인지 잘 모르겠습니다.

SSO가 활성화되어 있고 로그인하지 않은 상태에서는 배너를 표시하지 않도록 업데이트하는 것이 최소한은 되어야 하지 않을까요?

2개의 좋아요

@blake 개인적으로 이건 스태프에게만 표시되어야 할 알림이라고 생각합니다.
일반 사용자는 이 알림에 대해 할 수 있는 것이 거의 없으며, 왜 이런 메시지가 보이는지 그리고 그 의미가 무엇인지에 대해 토픽을 여는 것 정도가 가능할 뿐입니다.
그냥 잘못된 사람들에게 표시되고 있는 것뿐이죠 :wink:

참고로: 제 사이트에서는 CSS로 이 메시지를 숨겼지만, 이 메시지가 표시되어야 하는 경우도 있을 수 있으므로, 배포 코드에서 이를 해결하는 올바른 방법은 아닙니다.