사용자가 전체 이름을 변경하지 못하도록 방지

모두 안녕하세요,

관리 중인 포럼에서는 사용자명에 대해 비교적 많은 자유도를 부여하고 있지만, 이용약관에 따라 사용자는 성명을 기재해야 하며, 법적 이름 변경 외에는 이름을 변경할 수 없도록 하고 있습니다. 아직 사용자 수가 많지 않음에도(250명 미만) 이미 일부 사용자가 이 규칙을 지키지 않는 경우가 발생하고 있습니다. 따라서 이를 강제할 수 있는 방법이 필요합니다.

요약하자면, 계정이 승인된 후에는 관리자나 모더레이터만 성명을 변경할 수 있도록 해야 합니다. Discourse에서 이 기능을 구현할 수 있는 방법이 있을까요? 문서를 살펴봤지만 방법을 찾지 못했습니다.

가능하지 않다면, 이 기능이 코드에 추가될 수 있을까요?

감사합니다

3개의 좋아요

단순하지만 피할 수 있는 해결책은 CSS로 편집 버튼을 숨기는 것입니다. 똑똑한 사람은 여전히 편집할 수 있습니다. 이를 강제하려면 플러그인이나 SSO가 필요할 수 있습니다.

4개의 좋아요

답변해 주셔서 감사합니다. 이미 그런 플러그인이 있는지 혹시 알고 계신가요? 없다면 직접 시도해 보겠지만, 마지막으로 코딩을 한 게 정말 오래전에 한 일이라서요 :frowning:

2개의 좋아요

플러그인이 존재하지 않는 것 같습니다. 하지만 CSS로 우회하는 방법은 Firefox나 Chrome에서 검사(Inspect) 기능을 사용하여 숨기고 싶은 박스를 클릭한 후, 테마의 CSS를 편집하는 것입니다:

2개의 좋아요

여기서 가장 강력한 옵션은 “auth overrides username” 옵션을 사용하여 외부 인증 제공자(OAuth 등)를 사용하는 것이라고 생각합니다.

모든 로그인 시 로컬 전체 이름을 외부 사이트의 전체 이름으로 덮어쓰고, 로컬 변경을 방지합니다. 모든 인증 제공자에 적용됩니다.

1개의 좋아요

그렇게 하면 문제를 해결할 수 있지만, 제3자 서비스를 포함하는 것은 사용자가 자신의 이메일 제공자를 자유롭게 선택하는 것을 선호하는 우리 중 많은 사람들에게 좋은 선택이 아닙니다.

"외부"라고 할 때, "제3자"를 의미하는 것이 아니라 "디스코urs 외부"를 의미합니다. 제3자 솔루션을 사용할 수도 있고, 직접 운영할 수도 있습니다.

우리 자신에 대한 신뢰와 Discourse 코어 팀에 대한 신뢰는 다릅니다. 이 팀은 이 시스템을 처음부터 끝까지 구축한 최고의 전문가들이에요.

제가 하고 싶은 말은, 가장 강력한 해결책은 가장 우아한 해결책이라는 뜻은 아니라는 거예요. 스위치로 해당 옵션을 비활성화하는 것이 가장 좋은 방법일 수 있다는 뜻이에요.

1개의 좋아요

안녕하세요,
제안해 주셔서 감사합니다. 하지만 안타깝게도 현재로서는 이 옵션을 사용할 수 없습니다. 중앙 SSO가 없으며, 그 관리는 제가 감당하기에는 훨씬 더 복잡한 일입니다!

현재로서는 CSS 조작 정도가 제가 할 수 있는 한계일 것입니다. 제가 관리하는 것은 클럽 포럼이며 모든 회원이 신원이 확인된 상태입니다. 단순히 비활성화되어 있고(규칙에 의해 금지되어 있음) 있음에도 불구하고 이 변경을 강제하는 것은 사용자의 계정이 읽기 전용으로 전환되거나 완전히 비활성화되는 사유가 될 것입니다.

@satonotdead 님, 제공해 주신 링크에 감사드립니다. 이 내용을 살펴보고 변경 사항을 쉽게 처리할 수 있는지 확인해 보겠습니다. 장기적으로, 시간이 될 때(은퇴할 때까지 15년 이상을 기다려야 할 수도 있습니다 :sweat_smile:) 플러그인을 작성하는 데 투자하는 것도 고려해 볼 수 있습니다…

2개의 좋아요

하이브리드 솔루션이 작동할까요 @AriesFR ?

Jay @pfaffman 의 CSS로 숨기는 제안대로 한 다음, 사용자 정의 필드를 만들고 설정을 다음과 같이 구성해 보세요:

:thinking:

2개의 좋아요

음, 실제로 작동할 수도 있겠지만, 그래도 현재 전체 이름에 대해 지정되어 있는 것처럼 사용자 이름 옆에 표시되기를 원합니다.

일단, 사용자의 프로필 업데이트 섹션에서 전체 이름 섹션을 숨기는 것이 괜찮은 임시 해결책이 될 것입니다. 자기 자신에게 해가 될 정도로 지나치게 호기심 많은 사용자들의 예외 상황도 여전히 처리할 수 있으니까요.

사용자 이름처럼 이 잠금 옵션을 기본 제품에 포함하는 것이 왜 그렇게 큰 문제인 것인지는 여전히 이해할 수 없습니다… 매우 독단적으로 보입니다.

[조크 모드 켜짐]
우리 자신을 위해 좋다고 해서 사용자 서명을 허용하지 않는 것과 비슷하네요.
[조크 모드 꺼짐]

확인해 보았는데요. API를 통해 필드를 숨기는 것은 가능하지만, 해당 사용자가 승인되었는지 아닌지를 확인할 수 있는 신뢰할 만한 데이터를 찾을 수 없습니다(설정 페이지 컨텍스트에서) :thinking:

현재까지 작성해 둔 코드는 다음과 같습니다.
죄송한 마음이 들지 않아야 할지 모르겠네요. 여기가 좀 해킹적인(hacky) 방식인 것 같습니다. :smile:

js
<script type="text/discourse-plugin" version="0.8">

const { setting } = require("discourse/lib/computed");

api.modifyClass("controller:preferences/account", {
  pluginId: "hide-name-in-preferences",

  get canEditName() {
    const enables_name = setting("enable_names");

    if (enables_name && this.isCurrentUser && !this.model.staff) {
      if (this.model.name) {
        // 입력 필드만 숨김 (이름은 표시됨)
        this.model.can_edit_name = false;
      } else {
        // 전체 섹션을 숨김
        return false;
      }
    }

    return enables_name;
  },
});
    
</script>
1개의 좋아요

그건 문제가 아니기도 하고 독단도 아닙니다. 대부분의 기능은 수요에 따라 우선순위가 결정되며, 이 기능에 대한 수요는 많지 않았습니다.

9개의 좋아요

감사합니다 @Arkshine, 제가 필요로 하는 것과 매우 비슷해 보입니다. 제 환경에 이걸 어떻게 포함시킬지 알아봐야겠지만 :slight_smile:, 아마 이번 주말까지는 적용할 수 있을 것 같습니다.

감사합니다. 우선순위를 정하는 건 이해할 수 있지만, 전역 메커니즘은 이미 존재하며 제가 볼 수 있는 한 사용자들로부터 여러 번 요청받은 적이 있습니다. 패치가 Arshkine가 방금 제공한 것만큼 단순하다면, 다른 필드에는 제공했던 같은 "배려"를 이 필드에는 제공하지 않은 것이 의도적인 선택이었다고 생각합니다.

잘못 알아들지 마세요. 여기에서 개발된 이 소프트웨어는 정말 훌륭한 것입니다. 제가 관리하는 포럼에서 볼 수 있는 한, 완벽하게 작동하는 것 같고, 그것이 얼마나 어려운 일인지 잘 알고 있습니다. 다만 모든 결정에 동의하는 것은 아니며, 제시된 일부 근거는 때때로 독단적이거나 권위적으로 느껴집니다. 하지만 이것이 현재로서는 가장 좋은 소프트웨어라는 사실에는 변함이 없습니다.

감사합니다

테마 컴포넌트는 안전 모드(safe mode)를 사용하거나 브라우저에서 설정을 수정하는 방식으로 우회할 수 있습니다.

개발은 주로 CDCK/Discourse.org에 호스팅된 사용자들에 의해 주도됩니다. 왜냐하면 그곳에서 수익이 발생하기 때문입니다. 때로는 많은 사람들이 특정 기능을 원하거나 필요로 하면 해당 기능이 추가되기도 하지만, 만약 그 사람들이 CDCK에 비용을 지불하지 않는다면, 그 사용자가 매우 많아야 하거나, 많은 유료 고객이 만족할 것으로 보이는 기능이어야 합니다. 참고로 저는 그 회사에서 일하지 않으므로, 이는 지난 거의 8년간의 경험을 바탕으로 한 제 관찰일 뿐입니다.

5개의 좋아요

맞습니다! 비관리자가 안전 모드를 사용하지 못하도록 enable safe mode 설정을 비활성화하는 것이 좋습니다.

3개의 좋아요

아! 그걸 놓치고 있었네요. 브라우저 개발자 콘솔을 잘 다루는 사람은 여전히 우회할 수 있습니다.

1개의 좋아요

감사합니다. 이 매개변수를 보지 못했네요. 이제 비활성화했습니다!

1개의 좋아요

추측해 보자면, 이 기능을 원하면서도 유료 고객인 _대부분_의 사람들이 이미 어떤 형태로든 SSO를 가지고 있을 가능성이 높다고 생각합니다. 따라서 다른 모든 사람에게 이 기능은 더욱 니치(특정 소수 대상) 기능이 될 것입니다.

3개의 좋아요

가입할 때 사용자가 입력한 전체 이름을 인증하는 조치를 취하고 있는 것 같지 않습니다. 따라서 사용자가 이름을 Bob Jones에서 Sam Smith로 변경한 경우, 어느 쪽이 사용자의 실제 이름인지 어떻게 알 수 있을까요?

2개의 좋아요