Bug 221218 - Prevent certain accounts from being assigned and cc'd
Summary: Prevent certain accounts from being assigned and cc'd
Status: In Progress
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Only Me
Assignee: Kubilay Kocak
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2017-08-04 09:54 UTC by Mathieu Arnold
Modified: 2020-01-14 05:12 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Arnold freebsd_committer 2017-08-04 09:54:40 UTC
It would be great if freebsd-port@FreeBSD.org, freebsd-ports@FreeBSD.org, port@FreeBSD.org and ports@FreeBSD.org could not be added to any email fields.
It creates spam on the list.
Comment 1 Mathieu Arnold freebsd_committer 2017-08-28 09:11:07 UTC
ping.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2017-08-28 09:29:58 UTC
Hi mat. I haven't forgotten, and will continue to work on this. Things I'm looking at:

1) Getting counts of bugs for each account mentioned, and understanding their previous use, where relevant. I had a preliminary count somewhere, but cannot find the file at the moment.

2) Identifying what if anything special (eg: reassignment, or merging) needs to occur for issues for each case depending on outcomes of (1), in order to remove those accounts.

The long and short of it will be that any unused accounts (that have no bugs associated with them) and that should not 'ever' be used in future, whether as assignee, cc or otherwise will be deleted, after removing any other references to them if they exist.

That is the only way to prevent their use.

I'll document each change made in this issue as I go
Comment 3 Mathieu Arnold freebsd_committer 2017-11-13 08:49:51 UTC
Let's add a few to the list, developers@ ports-developers@, docs-developers@.
Comment 4 Mathieu Arnold freebsd_committer 2020-01-06 13:21:54 UTC
poke.
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2020-01-14 05:12:44 UTC
I spoke with upstream to get a better sense of what's possible, in order to avoid as much as possible deleting users which has data integrity/reference implications, or customising bugzilla, with the following insights gained

1) There is a user admin setting "Disable Text", with description:

(If non-empty, then it will not be possible to log in using this account, and this text should explain why.) 

This setting apparently also disables returning this user in the JavaScript autocomplete when adding CC's / Assignees, etc. This needs to be tested/verified.

2) However, this does *not* prevent a disabled user from being able to *manually* (without autocomplete), because the "add cc / add assignee / etc" methods do not check for whether a user is disabled. This needs to be tested/verified.

3) There is an additional user setting "Disable Bugmail" with description:

(This affects bugmail and whinemail, not password-reset or other non-bug-related emails) 

If enabled, this would prevent a user from receiving 'certain', not *not* all classes of bugmail, in the event they are 'manually' added to CC/Assignee/etc fields.

4) Disable Bugmail doesn't prevent *all* bugmail. In particular, it doesn't prevent 'whines' and flag setting bugmail. This needs to be tested/verified.

5) Additionally there are the following per User Preferences (not User Settings in Admin) in https://bugs.freebsd.org/bugzilla/userprefs.cgi?tab=email

 Email me when someone asks me to set a flag
 Email me when someone sets a flag I asked for

Along with other "Field/recipient specific options" which can individually be enabled/disabled

However, it may not be ideal to disable *all* email, for example (but not limited to), we wouldn't want certain lists (including those in this issue) to be assigned to issues, and *not* know about it, as we don't want bugs with those users/lists as assignees and would want to correct that as they'd end up in a black hole.

I'll look into iterating from (1) through (5) after confirming each ones claimed behaviour.