Recently upgraded to Continua 1.7.0.108 (from some 1.6.0 version). Now everyone inside the company seems to get email notifications, when when we only import specific users into Continua CI.
Details:
* Middle-sized AD with several groups
* Users are created manually (linked to AD users)
* We created users only for developers
Pre-upgrade:
* Only developers part of specific groups that were configured to receive notifications (in the subscriptions tab) received emails
Post-upgrade:
* Everybody in the whole domain seems to receive build notifications now.
I double checked the configuration of Continua CI, and everything looks fine there. Only the developers are listed in the users sections and are part of the groups. The subscriptions are still going to the right groups.
Hi Geert,
I’ve look through the code but cannot see how this could happen. There’s not been any significant changes to this area for some time now. We’ll need to see a debug log to figure out what is going on. There was not much logging in that part of the code so I’ve uploaded a new build with extra debug logging.
- ContinuaCI Server (64 bit) v1.7.0.124
- ContinuaCI Agent (64 bit) v1.7.0.124
- ContinuaCI Server (32 bit) v1.7.0.124
- ContinuaCI Agent (32 bit) v1.7.0.124
Please can you install this and enable debug logging? Once the unwanted notifications have been sent, the debug log should have lines marked with [Notification Controller] showing details of each notification sent.
Thanks. We are investigating this. The logging seems to work and nothing strange happens. Will check the exchange environment as well (but it would be really coincidental that it happened together with the Continua CI upgrade).
1 thing that’s interesting is that the debug log says this:
Medium: 10:59:43 {T8} [Debug] [Notification Controller] Sending a notification type ‘Build Started’ via Email to members of the group ‘Build Contributors’ due to group subscription ‘02 - Development’. Number of users in group: 20
But when I go to the groups admin interface, it shows that the Build Contributors has 19 members.
People not part of the group are telling me that they are receiving emails (they are found as AD users when I click edit group in the interface, but the checkbox is disabled).
Hi Geert,
The count in “Number of users in group: 20” will include any archived users. We do, however, skip archived users when we iterate through those members to send notifications. I suspect that one of the members of the Build Contributors group is archived in the database, and this is why we are getting a different number in the logs.This doesn’t explain why non-users are getting emails.
Note that you cannot edit the members of groups which are linked to an LDAP group. The group should pick up the members from Active Directory. It should however only list those members which are registered or added as users to Continua. In our tests this seems to be working…
The only possibility I can see at the moment is that another user’s email address (or a distribution list email address) has been entered against a Continua user.
To investigate this further we need to identify one or more users who are receiving emails but shouldn’t be, and then search the log for their email address. There should be a line starting “[Notifications] Sending email notification to”. Then work the way back up the log to find the subscription that caused this.
Another thing to do would be to search for these email adddresses in the core_user table in the database and then check if the email address is in any subscription using the following SQL queries:
SELECT
s.
Name
as
“Subscription name”
, u.firstname, u.lastname, u.email, u.username, u.ldapsid, u.archived, u.enabled
FROM
core_subscription s
INNER
JOIN
core_user u
ON
s.userid = u.id
WHERE
u.email =
‘name@domain.com’
;
SELECT
s.
Name
as
“Subscription name”
, g.
Name
as
“Group name”
, g.ldapsid
AS
“Group ldapid”
, ldapname
AS
“Group ldapname”
, u.firstname, u.lastname, u.email, u.username, u.ldapsid, u.archived, u.enabled
FROM
core_subscription s
INNER
JOIN
core_group g
ON
g.id = s.groupid
INNER
JOIN
core_securityentitygroup seg
ON
seg.groupid = g.id
INNER
JOIN
core_user u
ON
u.id = seg.securityentityid
WHERE
u.email =
‘name@domain.com’