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 лайков

Герхард, ты знаешь, был ли когда-нибудь создан PR по этому вопросу? Мне нужен простой способ администрирования через фронтенд, чтобы каждый новый ID Discourse автоматически назначался в конкретную группу.

Например, я хотел бы просто ввести подстановочный знак * в поле «Пользователи, зарегистрировавшиеся с доменом электронной почты, точно совпадающим с одним из списка, будут автоматически добавлены в эту группу:» и быть уверенным, что все новые пользователи будут добавляться в группу, независимо от их адреса электронной почты.

1 лайк

В чём, собственно, смысл группы, которая включает всех пользователей? :thinking:

Я полагаю, что предполагается наличие нескольких групп, каждая из которых связана с отдельным доменом. Все пользователи, соответствующие определённому домену, будут автоматически отнесены к этой группе.

Примером использования может служить автоматическое создание групп, связанных с конкретной организацией (при этом известно, что участники группы принадлежат исключительно этой организации). Это было бы полезно для моего сообщества.

Нет, обратите особое внимание на то, что было сказано:

Я выделил жирным шрифтом соответствующий текст.

5 лайков