User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) KHTML/3.3.92 (like Gecko) Build Identifier: i have configured two queries for "my" bugs: bugs assigned to me and bugs reported by me. but this does not cover bugs where i don't play a main role. for those i can query by cc-entry, but unfortunately this gives no separation between the possible roles. not sure what a proper solution would look like, but two cc-lists seem most appropriate. Reproducible: Always
people here just setup two email accounts (or more) i have timeless-qa and timeless-assi jesse has jruderman+whenresolved which i suppose matches up w/ burning edge but to me seems to be a qa role. you mention co-reporter, that'd be a third role, no? complaintant, dev, qa.
> people here just setup two email accounts (or more) > how ugly. :} > you mention co-reporter, that'd be a third role, no? complaintant, dev, qa. > uhm, dunno. at kde we do no real qa for most "products", so this question didn't even come to my mind. :} you guys will certainly come up with a brilliantly generic makes-everyone-happy solution. :)
(In reply to comment #0) > for those i can query by cc-entry, but unfortunately this gives no separation > between the possible roles. I don't understand what you mean by "this gives no separation between the possible roles". You say you can query by cc entry, which is what I'd suggest, too -- what is missing or unwanted if you do?
if the reporter cannot be more explicit, I suggest to close this bug.
i really wonder how you manage not to understand, given that 'timeless' showed a workaround that pretty explicitly points out the issue. anyway, let's try again: for some bugs i'm the reporter, for some i'm the assignee. those cases are fine for listing; i can just use the respective fields as a search criterion. but then there are those bugs where i'm a "co-reporter" (i found my bug to be already reported) or a "co-assignee" (i'm not the responsible one, but want to see how things progress). for both cases i can put myself in the cc-list - which sucks for listing *only one of the groups at a time*, as there is only one cc-list.
It is going to be hard to justify the added UI overhead of an extra CC: list for such a niche request. What you want could be handled by CC: "types", where you indicated what sort of CC: subscription you had; however, the complexity that this beckons (extra forms or radio-buttons for each existing subscription) also makes our current UI look better and better. I found the "co-assignee" use case you gave to be rather obscure (I mean, anyone on the CC: list is in theory "interested on the progress of the bug"). The description of "co-reporter" is interesting, and we could actually implement a feature that allows filtering by reporter but that follows duplicates marked -- if you filed a dupe you would be specially treated in this search. I don't have a good idea of whether the complexity added would make the user model significantly more confusing that it currently is.
Ahh, I totally understand the problem here. I've also experienced that, somewhat. I think the best solution is to have two accounts, if you want that separation. I'd guess that the majority of users just use the CC field as "I want to know about this bug, for one reason or another." For some bugs I'm neither the co-assignee or co-reporter. Perhaps there's some more generic solution to the problem, but we'd probably want to come up with one that didn't add any complexity to Bugzilla.
yeah ... one problem is, that multiple accounts sort of defeat form autocompletion at login time. it's also not particularly convenient to have to change accounts in the first place (impossible to have the two accounts open at the same time, right?). complexity ... well, make it a per-user option and disable it by default. even if enabled, the role would default to an unspecified catch-all, both when adding and when searching. i guess a role combo next to the cc-add field and in the list the role in parentheses is simplest. assignments of myself by 3rd parties happen often and they probably would not (bother to make|see) the role assignment, so a sensible (and atomic) way of changing the role in necessary, too - maybe a second checkbox near the "delete marked cc:s": "change role of marked cc:s".
You can now tag bugs, which gives you an even better way to keep track of bugs you are the "co-reporter" or co-anything.