Site is locked down for members to be invited or request access.
We don’t want people changing their own email address, so the related email change site-setting is disabled. Of course, sometimes an admin must.
###Expectation:
go to the user’s admin page, see the email, and edit it, potentially have that pending confirmation of the new email.
###Actual
visit the admin page
click a button to see what it is.
there’s no way to edit it
Click Show Public Profile,
realize you have to click Preferences too.
No way to edit the email address… grrr
Go back to admin
disable the site setting
go back to publich profile/preferences
edit
go back to admin
disable the site setting.
As an admin, can we please just edit a user’s address at all times, from the Admin page?
Yeah, we are fine with allowing email/name/username editing on admin page. We must account for the sso override stuff though that disables editing here.
Of course, there are a couple of things that should be added related to this.
We should log all the name/email/username changes and have that visible somewhere
If an admin changes a users email, its probably sane to allow them to send an email right away to that user explaining that the email changed, doing this (optionally) automatically would be good.
As an admin, I can change an email now it just takes too many steps.
Addressing either (or both) of these two needs would help a lot"
Allowing an admin to change a user’s email from its Admin view (not only the public profile)
Allowing the change even if the site setting is disabled.
As for SSO, presumably the source of authentication already knows about the new email… the goal of the change in discourse would be to prevent an undesired second account from being created on the user’s next visit.
Currently this happens… we need to click an email confirmation link.
Maybe that would have to change when SSO is enabled, however I don’t think bringing the control from the user-side preferences to the admin side preferences changes the current SSO workflow.
مرحباً،
آسف لإحياء هذا الموضوع القديم ولكن سلوك ديسكورس يسبب مشاكل حقيقية في الوقت الحالي.
إذا قام مستخدم بتفعيل حساباته على منصتنا (ديسكورس هو مجرد منصة واحدة من بين العديد)، فإننا نقوم تلقائيًا بإنشاء مستخدم ديسكورد عبر واجهة برمجة التطبيقات (API). نحتاج إلى القيام بذلك لتعيين المجموعات الصحيحة. إذا قام المستخدم بتغيير بريده الإلكتروني قبل تسجيل الدخول لأول مرة إلى ديسكورس عبر ديسكورس SSO، فسيقوم بإنشاء حساب جديد (<username>1) وسيتعين علينا دمج الحسابين يدويًا.
السماح لواجهة برمجة التطبيقات (API) بتغيير البريد الإلكتروني سيساعد في تقليل الكثير من العمل اليدوي. وأعتقد أنه يجب السماح للمسؤولين أيضًا بذلك نظرًا لأنهم عادةً ما يعرفون ما يفعلونه.
أود منع المستخدمين من تغيير عناوين بريدهم الإلكتروني ولكن ليس المسؤولين وواجهة برمجة التطبيقات (API).
حل آخر سهل لنا سيكون إذا كان بإمكان Discourse SSO أو SAML الإعداد لتسجيل الدخول إلى الحساب بنفس الاسم بدون إجراء فحوصات تستند إلى البريد الإلكتروني. ولكن للأسف، يريد Discourse دائمًا أن يكون أذكى من أي شخص يستخدمه
