369078 - Allow assignee to be empty (blank)

Status: REOPENED

(bugzilla.mozilla.org :: Bug Creation/Editing, enhancement)

Description

[Gervase Markham [:gerv]]

There may be a technical reason why we can't do this, but... we should make it possible for the assignee to be blank.

At the moment, we use placeholder addresses like [e-mail] and so on in Bugzilla, so clearly the demand is there to have "no assignee". So why not go the next logical step and allow the field to be blank?

Gerv

Comment 1

[timeless]

you can't easily search for blanks, you certainly can't watch blanks. blanks are actually very hard to explain to users.

Comment 2

[Majken Connor [:Kensie]]

if it's not assigned to anyone, why are you trying to find it based on assignee?

Although I think I see your point, and in conjunction with allowing the assignee to be blank, we would want to automatically mark a bug as assigned when the field is filled in.

We could still have a placeholder [no one] that would be searchable.  This would just stop requiring the creation of a placeholder account.

Comment 3

[timeless]

I can easily want to look for bugs no one is working on. But I can't do that if I can't search for it.

Comment 4

[Jeff]

I see a very useful side benefit of this feature which would be to enable situations such as having a blank assignee only valid for bugs in particular states such as UNCONFIRMED. This would allow bugs to come in without an assignee but then force a user that confirms or accepts a bug to set the assignee. Even more restrictions could be place on a blank assignee such as only being valid when a bug is resolved with specific types of resolutions so that bugs resolved as INVALID or DUPLICATE can still be marked with a blank assignee.

Currently we use a special <nobody> user in our system which is really a hack since we have to specify a fake email address for this user and there is nothing stopping people from closing bugs as fixed while forgetting to change the assignee from <nobody> to themselves. So I find I'm going back to RESOLVED bugs and trying to discern who was the real assignee that fixed the bug, something that wouldn't be necessary with the proposed feature.

Note: The notion of a blank assignee isn't really necessary but instead just a special value that could be named and searched on such as <unassigned> or <nobody>. Then as I mentioned this special built-in user would be made more useful by allowing special handling with regard to STATUS and RESOLUTION.

Comment 5

[Frédéric Buclin]

Allowing no assignee for bugs would make product and component creation even easier. No need to specify a user as assignee. And we could reuse exactly the same code as for the QA contact field.

Comment 6

[Andre Klapper]

While I'm in favor of this change, removing the last requirement for an email ID coupled with one or more component(s) makes it harder to follow some components' tickets via (ab)using user watching the default assignee for them.
So before this is worked on I'd prefer to see ComponentWatching being upstreamed (cf. bug 1090493).

Comment 7

[Frédéric Buclin]

(In reply to Andre Klapper from comment #6)
> So before this is worked on I'd prefer to see ComponentWatching being
> upstreamed (cf. bug 1090493).

This bug shouldn't be blocked by ComponentWatching. If this is critical to you, then you should work on bringing it upstream, not the other way.

Comment 8

[Andre Klapper]

I never wrote it's "blocked by" - no idea where you got that from. 
After spending some time last year analyzing assignee workflow patterns of six bigger FOSS Bugzilla instances out there I naively though that upstream might be interested in making life of customers not necessarily harder than needed. Of course upstream is free to ignore recommendations and consider my opinion to be only "critical to me" (which actually isn't the case).

Comment 9

[Frédéric Buclin]

(In reply to Andre Klapper from comment #8)
> I never wrote it's "blocked by" - no idea where you got that from. 

"So before this is worked on I'd prefer ..." mostly means "blocked by" to me. :)

Anyway, you mentioned watching the default assignee as a way to track bugs in a given component. There is an obvious limitation here as once someone assigns the bug to himself, you wouldn't get bugmails for this bug anymore. This also means that you need one default assignee per component. That's why we implemented globalwatchers several years ago to let you track all changes, independently of who is the assignee. I think this is a better approach than watching the default assignee. If you need a finer approach and watching on a per component basis is really what you need, then component watching is something which would indeed offer you what you want, and this RFE has already been filed many years ago (2001!), see bug 76794, and nobody took the time to implement it. That's why I said "if this is critical to you", because it seems this is not critical enough to anyone to see someone implement it. Also note that admins are free to set a default assignee if this helps his users. But I see no reason to not allow them to leave the default assignee empty if that's what they want.

I hope the misunderstanding is solved. :)