CC'ing when sending LSs over datatracker

[mirjak]

Description

If people send LSs through the datatracker, the email generated comes from statements@ietf.org and the person listed in the From flied doesn't get a copy. It would be good to also cc that person, especially for cases where the LS was sent to statements@ietf.org and is uploaded by the secretariat manually. The original sender will get a note when the secretariat ticket is closed (and processed), however, it would be way nicer to have that person directly cc'ed in the send-out of the LS itself.

As a side note, if a LS is sent to a wg, the chairs show up in the To field and the mailing list only in the cc. That seems also unexpected. I would expect to have the wg list in To, either even just the list address or both the list address and the chairs directly. Sorry if this should be a separate issue, but it seemed easier for me to mention this here as well; also this part is not really a problem that needs fixing, it's more a note.

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[rjsparks]

The first change above (cc-ing the from contact) can be realized with a data adjustments. The mailtrigger concept was intended to make this kind of change easy.

We would need a new mailtrigger/recipient of liaison_from_contact expanding to {{liaison.from_contact}} and then that recipient would be added to the cc: recipients in https://datatracker.ietf.org/mailtrigger/name/liaison_statement_posted/.

I can make those changes as an incremental improvement through the admin.

The second (moving the group list (if the target is a group) to To vs CC requires adjusting code here:

datatracker/ietf/liaisons/views.py

Lines 100 to 158 in b1cfa70

	def get_cc(group):
	'''Returns list of emails to use as CC for group. Simplified refactor of IETFHierarchy
	get_cc() and get_from_cc()
	'''
	emails = []
	# role based CCs
	if group.acronym in ('ietf','iesg'):
	emails.append(EMAIL_ALIASES['IESG'])
	emails.append(EMAIL_ALIASES['IETFCHAIR'])
	elif group.acronym in ('iab'):
	emails.append(EMAIL_ALIASES['IAB'])
	emails.append(EMAIL_ALIASES['IABCHAIR'])
	emails.append(EMAIL_ALIASES['IABEXECUTIVEDIRECTOR'])
	elif group.type_id == 'area':
	emails.append(EMAIL_ALIASES['IETFCHAIR'])
	ad_roles = group.role_set.filter(name='ad')
	emails.extend([ contact_email_from_role(r) for r in ad_roles ])
	elif group.type_id == 'wg':
	ad_roles = group.parent.role_set.filter(name='ad')
	emails.extend([ contact_email_from_role(r) for r in ad_roles ])
	chair_roles = group.role_set.filter(name='chair')
	emails.extend([ contact_email_from_role(r) for r in chair_roles ])
	if group.list_email:
	emails.append('{} Discussion List <{}>'.format(group.name,group.list_email))
	elif group.type_id == 'sdo':
	liaiman_roles = group.role_set.filter(name='liaiman')
	emails.extend([ contact_email_from_role(r) for r in liaiman_roles ])
	# explicit CCs
	liaison_cc_roles = group.role_set.filter(name='liaison_cc_contact')
	emails.extend([ contact_email_from_role(r) for r in liaison_cc_roles ])
	return emails
	def get_contacts_for_group(group):
	'''Returns default contacts for groups as a comma separated string'''
	# use explicit default contacts if defined
	explicit_contacts = contacts_from_roles(group.role_set.filter(name='liaison_contact'))
	if explicit_contacts:
	return explicit_contacts
	# otherwise construct based on group type
	contacts = []
	if group.type_id == 'area':
	roles = group.role_set.filter(name='ad')
	contacts.append(contacts_from_roles(roles))
	elif group.type_id == 'wg':
	roles = group.role_set.filter(name='chair')
	contacts.append(contacts_from_roles(roles))
	elif group.acronym == 'ietf':
	contacts.append(EMAIL_ALIASES['IETFCHAIR'])
	elif group.acronym == 'iab':
	contacts.append(EMAIL_ALIASES['IABCHAIR'])
	contacts.append(EMAIL_ALIASES['IABEXECUTIVEDIRECTOR'])
	elif group.acronym == 'iesg':
	contacts.append(EMAIL_ALIASES['IESG'])
	return ','.join(contacts)

. We could do that now as incremental improvement, or wait until we rework the application and move all of that code into mailtriggers to ease future maintenance.

[rjsparks]

I can make those changes as an incremental improvement through the admin.

I've done this - see https://datatracker.ietf.org/mailtrigger/name/liaison_statement_posted/

[rjsparks]

Moved the second observation to its own issue.

[mirjak]

Thanks! Actually this is one of the issues where the discussion move on a bit. (Sorry I know this is a bit of a mess currently but that's also why a proposed to reorg the current issues maybe).

There are two cases: For outgoing liaison statements I think the email should be sent to all email address: all IETF related address but also the recipients from the other org because that's how actually send the statement out and by cc'ing IETF groups we also announce that is was sent in one go.

For incoming statements, we should only distribute the statements within the IETF as we acknowledge the receipt simply by email in an informal way usually, otherwise this could cause confusion. Or maybe we could have a separate check box that even says "Also send to From contacts"...?

In the long term we want to change the field for as example discussed here: ietf-tools/liaison-tooling-2025a#22

[rjsparks]

Do you want me to remove the liaison.from_contact that I just added to the cc until these details are settled?

[mirjak]

Could you easily add the liaison.from_contact only for out-going statements to cc and not incoming? For incoming it would only make sense if we also add a check-box to not do it (or maybe rather a check to do it if needed). If that is not easily possible maybe it better to not do this for now to avoid confusion.

[rjsparks]

There is no concept of outgoing or incoming in the mailtriggers yet. That will require code changes. I'll remove liaison_from_contact from the liaison_statement_posted mailtrigger for now.