Bug 1410325

Summary: Cannot set needinfo to rhcert-reviewers@redhat.com
Product: [Community] Bugzilla Reporter: Feng Wang <fwang>
Component: Bugzilla GeneralAssignee: PnT DevOps Devs <hss-ied-bugs>
Status: CLOSED NOTABUG QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.0CC: agk, huiwang, jfearn, pmao, qgong, rlandry
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 07:04:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Feng Wang 2017-01-05 06:48:42 UTC
Description of problem:
Tried to add needinfo to account 'rhcert-reviewers' (this is the default account used by Certification team) but failed.

Error message is:
You can't ask rhcert-reviewer <rhcert-reviewers> because that account is disabled.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

The bug entry is https://beta.bugzilla.redhat.com/bugzilla//show_bug.cgi?id=1399233

Comment 1 Feng Wang 2017-01-05 06:56:52 UTC
If Bugzilla 5.0 is designed to not allow setting needinfo flag to diabled accounts, then I think 'rhcert-reviewers' should be active.

Comment 4 Jeff Fearn 🐞 2017-01-16 22:41:30 UTC
I'll just drop my point here that setting flags for the attention of lists is no more useful than setting them for anyone.

Comment 5 MaoPeng 2017-02-28 14:25:42 UTC
Hi Jeff,

Just want to confirm with you, setting needinfo to a mail list or a group of people is not going to be supported in BZ 5 ?
This is going to have a big impact on the business side, we will have to change way of our supporting:
1. each reviewer will have to own a cert, instead of the reviewer group own the cert 
2. the partners have not bought a TAM won't be taking care, if there is no default tam list notified. 

Thanks,
Peng Mao

Comment 6 Jeff Fearn 🐞 2017-02-28 22:19:09 UTC
(In reply to MaoPeng from comment #5)
> Hi Jeff,
> 
> Just want to confirm with you, setting needinfo to a mail list or a group of
> people is not going to be supported in BZ 5 ?

Close enough, you can't needinfo an account that can't login, and mailing lists are among the list of account types that have login disabled.

> This is going to have a big impact on the business side, we will have to
> change way of our supporting:
> 1. each reviewer will have to own a cert, instead of the reviewer group own
> the cert
> 2. the partners have not bought a TAM won't be taking care, if there is no
> default tam list notified. 

Own in Bugzilla means assignee, notified means you are on the CC list, this change doesn't impact either of those things so I'm not sure what you mean here.

Comment 11 Alasdair Kergon 2017-04-10 20:49:12 UTC
Setting needinfo to a list is probably a common a requirement across many products e.g. where a list is the default component owner and the bug hasn't (yet) been assigned to an individual.

If a disabled account can be a meaningful assignee on an open bug, then it needs to both have mail sent to it and to be available on specifically requestable flags.

(I'd still prefer a solution that tagged mailing list accounts in a specific way e.g. as members of a generalised 'no_unsub_link' group to which properties like this one could be attached.)

Comment 12 Jeff Fearn 🐞 2017-08-01 07:04:31 UTC
This is an upstream change and I'm reluctant to add technical debt given the arguments presented so far.

If you have workflows that need the attention of a group, then the currently supported way of doing that is using a flag or custom field. 

I'd recommend a flag as they are easier to create and you have much better control over who can view or request, or grant them.

A dedicated flag is better for this and doesn't cost us any technical debt, seems pretty straight forward to me.