936961 - The eng-team-all@ alias script shouldn't rely on the LDAP "is a manager" bit being set correctly

Status: RESOLVED WONTFIX

(Infrastructure & Operations :: Infrastructure: Mail, task)

Description

[Ed Morley [:emorley]]

+++ This bug was initially created as a clone of Bug #935512 +++

In bug 935512, several users were not receiving emails sent to the eng-team-all@ list, due to their manager's "is a manager" bit not being set correctly.

Whilst those specific cases have been fixed, there are still yet more people not receiving emails for the same reason - and whilst the LDAP data being wrong is the root cause - until we have an automated report for discrepancies (bug 935590) or else HR's Workday software synced with LDAP, we should not rely on the accuracy of this field.

As such, we should just rely on the "who is my manager" LDAP field to create the tree that we then traverse from Brendan downwards, in order to generate the list of people for the eng-team-all@ alias. The "is a manager" bit would seem like just a perf optimisation to avoid having to traverse the whole tree of employees listed on LDAP, however bug 935512 comment 10 implies there may be more to it - though I really doubt there isn't a way we can do this.

Comment 1

[Ed Morley [:emorley]]

Note I've sent an email to eng-team-all@ advising not to use this list until this (or alternatively the LDAP-Workday sync) is fixed.

Comment 2

[Rob Tucker [:rtucker]]

The solution is to get someone from HR to take my audit report and correctly update the isManager bit.

There are reasons why this bit should be set correctly and regardless of the opinion that it is simply a performance optimisation, it is necessary for the isManager bit to be set correctly. These reasons go further than the engineering email distribution lists.

I can quickly create the report, I simply need a destination email address of someone in HR who will either set the isManager = TRUE, or remove the direct reports from the manager in question.

Comment 3

[Rob Tucker [:rtucker]]

Per https://bugzilla.mozilla.org/show_bug.cgi?id=935590#c7 I'm going to WONTFIX this.
We now have the proper eyes on the report to confirm the accuracy of data in LDAP