Exclude certain email sub-domains from automatic group membership

I’m looking at the automatic group membership setting (in group settings). It states

Users who register with an email domain that exactly matches one in this list will be automatically added to this group:

Am I correct in assuming that entering bar.com will also trigger membership for emails ending in foo.bar.com? Or is the word “exactly” meant to state that exactly that is not the case?

Assuming that my assumption is correct, I’m looking for a solution for the following:

Goal: All employees (and only employees) of a university should automatically get membership in the group employees .

Strategy: Use the university’s domain uni.edu in the above setting to automatically assign membership

Problem: Student email-addresses also end in uni.edu but they should not get access to the group.

Possible solution: If I could exclude student.uni.edu from getting automatic membership, that should work, but I believe this is currently not possible. Or am I missing something? Any smart workarounds?

1개의 좋아요

It already works that way.

It matches the full domain after the @, so when you configure your group to automatically assign membership for uni.edu it will match foo@uni.edu, but not foo@student.uni.edu

4개의 좋아요

Ah, okay, then my assumption was wrong. But then my issue is another one: I need some sort of catch-all for *.uni.edu because it is impossible to predict the exact sub-domain of an employees email-address. Some have uni.edu, but many have various subdomains like sociology.uni.edu, depending on their departmental affiliation or what they chose as their main affiliation or whatever other determinants there may be.

Is there any way to catch all of these without being able to provide a full list of all possible sub-domains?

Unfortunately that’s currently not possible.

What would it take to create a plugin/PR that would make *.uni.edu work, i.e. that it would catch all users with an email address ending in uni.edu, regardless of whether there is a subdomain or not? My hunch is that it should be pretty easy (read: I might be able to do it), but maybe I’m wrong?

4개의 좋아요

Sure, I think a PR that adds support for wildcards would be fine.

Search for automatic_membership_email_domains in the code if you want to give this a try. It’s used in a couple of files.

5개의 좋아요

Gerhard님, 이 기능에 대한 PR이 실제로 생성된 적이 있는지 아시나요? 모든 새 Discourse ID가 생성될 때 특정 그룹에 자동으로 할당되는 쉬운 프론트엔드 관리 방식을 원합니다.

예를 들어, “이 목록에 정확히 일치하는 이메일 도메인으로 가입한 사용자는 자동으로 이 그룹에 추가됩니다:” 필드에 와일드카드 문자 *만 입력하면, 이메일 주소와 관계없이 모든 새 사용자가 해당 그룹에 가입하도록 하고 싶습니다.

1개의 좋아요

모든 사용자가 포함된 그룹의 정확한 목적은 무엇인가요? :thinking:

의도는 여러 그룹을 만들어 각각 다른 도메인과 연관시키는 것이라고 생각합니다. 특정 도메인과 일치하는 모든 사용자는 해당 그룹에 배정됩니다.

사용 사례로는 특정 조직과 연관된 그룹을 자동으로 생성하는 것이 있습니다(그룹 멤버가 해당 조직 소속임을 알고 있는 경우). 이는 제 커뮤니티에서 유용할 것입니다.

아니요, 구체적으로 어떤 내용이 언급되었는지 주목하세요:

관련 텍스트를 굵게 표시했습니다.

5개의 좋아요