I set up a discourse server for a client and let them create test accounts, which I knew will ultimately become obsolete once the SSO was in place. I set everything up, customised my theme and wrote category descriptions for everything using my admin account A.
Once I had DiscourseConnect setup (as the only sign-up option) I signed in with my admin account from the other system and granted that account B admin rights. From here on I would do anything under account B, as I couldn’t log in as A anymore.
Then I happend upon the “impersonate” button and got curious. Seemed like I didn’t have to delete account A, if I could just impersonate them to edit category descriptions, FAQs etc. So I used B to impersonate A and did a bunch of edits to test and everything was great.
Until I got curious if I could impersonate the forum’s bot account as well. So, while still impersonating A (who happened to be an admin) I decided to impersonate C. It worked, great stuff, so diligently I logged out and went about my day.
Now, when logged in as B I can no longer impersonate A or C (other users are fine). The spot where the button should appear just reads “Admins and moderators can’t be deleted”.
The logs say that “B impersonated A” and “A impersonated C”.
I wasn’t sure whether this warrants a bug report - as I currently have no way of reproducing my steps - or if there was an easy way to fix this?
I didn’t know this route existed! That definitely solves the problem of circumventing DiscourseConnect, though I haven’t been able to untie the knot so to speak. Impersonate buttons show up for user A though, so I’m assuming they’re currently not impersonating anyone?
I just wrongly assumed that if you’re deliberately hiding the information from admins, then it wouldn’t be public. 2.8.0.beta4 it is.
Regarding your second suggestion, I don’t want to do that as user A has no equivalent on my other system, however any user can potentially have an account on the forum.
That’s about the bottom of my tiny barrel of knowledge. I wasn’t sure if admins could impersonate other admins (I thought it was only developers). Did you remove Admin B from this list?
Hopefully someone with deeper knowledge pockets can chip in with something more salient.
I would suggest you add your Account B to the Dev section in the app. yml like @JammyDodger mentioned.
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'gavin@truecode.co.za'
)
