People with "canconfirm" should be able to mark bugs as DUPLICATE and WORKSFORME. See the suggested new workflow here: http://steelgryphon.com/testcases/bugzilla-workflow-9.png Adding a "READY" state is the other thing that proposal requires; but it's a lot more work, and we shouldn't let the best be the enemy of the good. Let's do the easy stuff ASAP. Gerv

you mean they can't, now? FYI, we recently took a change that stops people without editbugs from twiddling dependencies... Asa said that was fine because he never gives anyone canconfirm without editbugs anyway. Seems like the same would apply here.

The current default implementation of CheckCanChangeField() (process_bug.cgi, beginning around line 408) only allows people with canconfirm to confirm bugs, not do anything else. The dependency thing was necessary, I believe, because dep changes don't currently go through CheckCanChangeField(). If we want to merge canconfirm and editbugs, we should announce that, discuss it and do it. But the current consensus on how Bugzilla workflow should work (see that diagram) seems to see a distinct role for the two states. I usually give people what they ask for; if they don't ask for both, they don't get both. Gerv

We shouldn't be merging canconfirm and editbugs. For example, people with canconfirm should not be able to (at least): 1) Resolve bugs wontfix 2) Change target milestones, priorities. I believe there was talk of renaming canconfirm to cantriage and sorting out exactly what users with that privilege should be able to do.

IMO, there's no real need to go through the hassle of actually renaming canconfirm as cantriage in order to bend the role slightly in the way outlined by this bug. We can think of it as "cantriage", but internally it can still be called "canconfirm". Gerv

Sure. As long as we conceptually rename it (and possibly in the bugzilla UI for editing permissions).

The entire point of this is to make canconfirm more useful to basic triage, so we can just give one and not the other, to a wider audience than we currently can.

Here's a patch. I've tested it, and it seems to work. Someone will need to review it and put it on b.m.o, as I'm now away for four weeks. Gerv

Dave: can you review this and put it up on b.m.o.? It helps implement the Bugzilla workflow which bz, mike and others have developed. Gerv

i think most people want this for bugzilla proper. if someone actually objects we can make this a param or provide a cantriage group which defaults to being inherited by canconfirm but with no default members, so that people who like the current useless group can keep that behavior.

i don't see a way of marking blocking-trunk? but i'd like to request that we actually get this in in time for the next bmo upgrade.

Not a 2.22 blocker (we branched already)

Will this still have a possibility to work with WORKSFORME now that we have custom resolutions from bug 94534?

*** Bug 120151 has been marked as a duplicate of this bug. ***

Here's an unrotted and rewritten version against the tip. Hoping to get this for the next b.m.o. upgrade.

Comment on attachment 245454 [details] [diff] [review] Patch v.2 >Index: Bugzilla/Bug.pm >+ # On b.m.o., canconfirm is really "cantriage"; users with canconfirm >+ # can also mark bugs as DUPLICATE and WORKSFORME. This comment about b.m.o has nothing to do here. Bugzilla is not b.m.o and we shouldn't mention b.m.o at all in comments. >+ elsif ($field eq "resolution" && >+ ($newvalue eq 'DUPLICATE' || >+ $newvalue eq 'WORKSFORME')) I don't like hardcoding WORKSFORME. This resolution is no longer hardcoded since we allow you to customize your list of resolutions. The only harcoded resolutions are FIXED, DUPLICATE and MOVED. >Index: template/en/default/bug/knob.html.tmpl >+ [% NEXT IF r != "WORKSFORME" %] Same remark here. I don't have time to review it now, so letting the review flag unchanged (for now).

LpSolit: this patch is intended for b.m.o. only. I don't know if there's a consensus that we actually want it for Bugzilla proper. (Maybe it's in the wrong component and product.) If we did want it for the trunk, we'd probably need to rename "canconfirm" as "cantriage". Gerv

(In reply to comment #16) > LpSolit: this patch is intended for b.m.o. only. I don't know if there's a > consensus that we actually want it for Bugzilla proper. (Maybe it's in the > wrong component and product.) If we did want it for the trunk, we'd probably > need to rename "canconfirm" as "cantriage". I have no problem keeping the name "canconfirm" as you "can confirm" that a bug is a dupe or invalid/wfm. And this name is internal only anyway. :) I'm fine letting users with canconfirm privs mark bugs as dupes, even in Bugzilla the product. Also, WFM makes perfect sense too. The only problem is that you can have some installations where this resolution no longer exist. My suggestion is that you remove the code about WFM, remove the comment about b.m.o, and only keep the part about dupes. And this can go into Bugzilla 3.0. About WFM, you can then open a separate b.m.o-specific bug to include it as well. For Bugzilla 3.2, this will probably be part of the workflow stuff, which will let you define your own rules. If you want it in Bugzilla 3.0 (which is the version b.m.o will upgrade to), you have 24 hours before we freeze.

LpSolit: I won't have a chance to update the patch until 10pm GMT tonight... Is that quick enough? Gerv

Hmmm, should this perhaps be a b.m.o-only patch? It'll break as soon as somebody renames WORKSFORME to WORKS_FOR_ME, for example...

(In reply to comment #19) > Hmmm, should this perhaps be a b.m.o-only patch? It'll break as soon as > somebody renames WORKSFORME to WORKS_FOR_ME, for example... > Marc, yeah, that's why I suggested to attach a patch for DUPLICATE only, read comment 17. ;) Anyway, the trunk is frozen now.

what's the status of this now? b.m.o only patch for now?

This patch is intended for b.m.o. only, and implements a feature that Mozilla developers have been asking for for a long time. Let's not get distracted with its applicability or otherwise to Bugzilla proper. Dave: can I get a review here, so this can be applied during or after the upcoming b.m.o. upgrade? Gerv

Per gerv's last comment, this is a patch for b.m.o only.

justdave or reed: ping? Who has the power to apply this to b.m.o.? Gerv

Ok, I have this patch up on https://landfill.bugzilla.org/prodpatches/ for testing.

justdave, let's see if we can get this on bugzilla-test for some real testing. huge-bmo-patch11.diff contains it.

Comment on attachment 245454 [details] [diff] [review] Patch v.2 This seems to be working with the testing I've done. I'll continue to do more testing once it is on bugzilla-test.

This went live Thursday night. Please start using it! :) The only thing I think we may want to add is the ability for cantriage people to resolve things as INCOMPLETE. Gerv, want to work on a supplemental patch for that, or I can just do it sometime next week or so?

(In reply to comment #28) > The only thing I think we may want to add is the ability for cantriage people > to resolve things as INCOMPLETE. Gerv, want to work on a supplemental patch for > that, or I can just do it sometime next week or so? Never mind. I just made this change myself. It should go live the next time Bugzilla is upgraded.