Continuing the discussion from Add Mozilla staff to a group:
Discourse has the in-build ability to add all people login with a specific email domain to be automatically added to a group.
We can just test this with a staff group and these domains?
‘mozilla.com’,
‘mozillafoundation.org’,
‘mozilla-japan.org’,
This would allow us to:
That’s a quick and hack-ish way of doing it (and depending on time restrictions it might make sense), but the right ™ way to do identity/group management is through mozillians.org api and not based on emails domain part.
I agree with Nikos, that feature isn’t really designed to be a proper access management solution (what happens when people leave mozilla?)
I have only seen staff posts flagged a handful of times, and they are usually resolved quickly. I’m not sure if this reason is urgent enough to handle access this way.
This is probably a discussion in itself - Should staff be distingushed by title by default? What value does it add?
Persona doesn’t require that you authenticate with Okta every single login, so people would still be a part of the group for up to a month after they leave. It’s unclear whether Auth0 will have the same behavior.
Interesting, so that’s also a problem right now to all mozilla sites using persona?
Indeed, see the “Persona had its own passwords” section in this post-mortem of Persona. I assume LDAP will be the same.
e: That also does not take into account the “Remember me for one month” feature I was talking about - that also did not require authentication each time.
What’s the problem we try to solve here? Why do we need to identify paid staff?
I’d prefer that at some point we are able to identify NDA contributors (both paid and volunteers).
If nobody has anything to add here before Wednesday, I will assume we can wait for some type of mozillians integration before adding a staff/NDA group.
This is coming from a conversation on the private staff yammer about the future of yammer now that it will be integrated with Office360. If discourse is able to accommodate some current needs with low effort, it would be easier to advocate for its use inside the org.
I totally agree, but I don’t think we’d be able to manage the group to ensure it is up to date. Staff should be able to trust that only other current employees will be able to see their posts.
If we can come up with a way to manage it until we get mozillians integration I’d be happy to implement it.
I think that would depend on the ETA for mozillians integration.
Not for a while.
The timeframe is important to evaluate this. 2 months maybe is ok, 6 months maybe not.
So to be clear, if that’s not going to happen before the end on the year, I think we should figure out a quick way to have at least staff and NDA mozillians group integrated. The staff group could use a similar approach I suggested and for NDA mozillians I know @leo already had some code ready and working.
I’ll be a bit controversial 
I’d say it should be either staff+nda or nothing at all. I’d prefer we don’t encourage an “employees-only” mentality.
The nice thing about Discourse is that we can very easily move threads that don’t need to be staff only (read: pretty much everything on yammer) to somewhere more public. It just requires some smart UX.
But yes, I think staff + nda has more use-cases.
Agree and at the same time there is just a few things (bonuses, office stuff) that could relevant just to staff.
End of this month is doable in terms of testing (and fixing any bugs which have appeared in) discourse-mozillians. Ideally we’d have a staging server set up identically to this one to do that thoroughly. @yousef do we currently have a functional staging server?
Also we’re going to want an elevated API key to ensure that everybody in the NDA group is included, not just those who have their groups publicly viewable. (Which also means we need to make the Discourse group membership private.) The form to request one is here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Participation%20Infrastructure&component=API%20Requests
Currently only the plugin only queries the nda group. Are all staff in that group?
Furthermore, it wouldn’t really be possible to have a staff-only category while volunteers are admins.
No, NDA group is only for volunteers. Staff is already covered by nda in their contracts.
Detecting staff emails is easy (by domain), forcing to re authenticate if the email is deactivated is the issue currently with persona. How does airmo handle this problem?