Closed Bug 37613 Opened 25 years ago Closed 22 years ago

"Accept bug" or "Take bug" functionality

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Type:
enhancement

Tracking

()

Status:
VERIFIED DUPLICATE of bug 35195

People

(Reporter: seth, Assigned: justdave)

References

Details

(Whiteboard: [flow:status] [people:owner])

Attachments

(2 files)

Take bug patch.
1.49 KB, patch
Details | Diff | Splinter Review
patch to make the accept bug line assign it to the person doing the accepting
1.20 KB, patch
Details | Diff | Splinter Review
"Take bug" is a radio button on the bug form, which reassigns the bug to the userid you are currently logged in as. The patch for this is attached.
Attached patch Take bug patch. — — Splinter Review
I do not like the "Take bug" idea very much. In my mind, "accepting" a bug is the same as "taking it". The current Bugzilla operation of "accept for someone else" seems to be feature few would (or should) use. I suggest altering the "Accept bug" to assign to the acceptor as well. If you insist on adding anothe button to retain the old functionality, add a "Accept on behalf of assignee". IMHO (as always), Mark Hamby
I disagree with Mark. I think that Accept and Take provide two different functions. To me, Accept assigns the bug to the current owner and Take reassigns the bug to me. Perhaps a compromise is a seperate ability to either customize the associated labels with each function and / or specify which funtions are available in an installation. However, I don't think the solution is to change what Accept means, or to drop the concept of Take, because I know that in some installations one or both of those functions are used with their current meanings.
I do agree with Mark. Look up "accept" in the dictionary and see what it says. :) I rest my case. Someone who's new to bugzilla will think they're taking the bug for themselves if you click that button. (I did until I found out the hard way). I think maybe a good compromise would be to leave Accept there, but double it up and clarify it. i.e.: (*) Leave as NEW ( ) Accept bug for yourself ( ) Accept bug on behalf of $current_owner etc.
This is a different statement than what Mark said. I do not want to remove the functionality that already exists (i.e., I want to keep the ability to assign a bug to someone else), which is what (I think) Mark wanted to get rid of. I agree that Accept Bug is misnamed. My preference would be : <> Mark bug as assigned to $current_owner <> Reassign bug to yourself [] and accept bug (Change status to Assigned) Or something along those lines.
That is acceptible to me. It gets the point across and adds functionality without removing any.
Is it an appropriate for someone to be able to assign the bug to the correct owner? Should there be permissions? Personally, I don't think so. ASSIGNED is supposed to mean that the bug is assigned to the "proper person". I know I wouldn't be that happy if some yahoo on the Internet assigned a bunch of bugs to me. There is a patch for bug 25273 that will allow you to accept the bug for yourself. I consider this to be the proper behaviour and have implemented it for our in house bugzilla.
Adding myself to cc. Tara, we need to hook up with Netscape folks too on this. If this is - every bug assigned to a person has to get accepted by that person, and sits in a que until then, this is bad. Spam-a-rama :-(
Seth: I suggested to Tara an alternate method of making this work, and she concurred. Rather than a new radio button on the form (which just adds more complexity), have the "accept" button be configurable via params to EITHER allow accepting bugs for others, OR reassign but to yourself on accept. I've begun working on a patch to do just this. The name is "reassigntoselfonaccept", and defaults to "off" (or 0). Like the idea, or hate it?
I think it is a decent idea, but I *REALLY* want to have the capacity to do both. There are times where I want to mark a bug assigned to someone else, and times where I want the shortcut to reassign a bug to myself. The solution I'd propose is to have buttons themselves configurable. i.e., I want a new button called Accept Bug For Me (or something like that), which changes ownership and sets it as assigned. Params would turn this button on or off. Furthermore, the current Accept bug button would be configurable in the same manner. This would allow one or both of these options to be available.
I guess the question comes down to: Is it reasonable for someone else to set your priorites in this way? Since ASSIGNED bugs should be worked on before NEW bugs, you are giving this bug a higher priority then every other NEW bug that assignee has. If this is acceptable, then you should be able to ASSIGN bugs that don't belong to you. If it's not, then accepting a bug should ASSIGN it to you instead of the current owner.
I know, I read somewhere that the idea of "NEW" was not priority, but "unseen", similar to REOPENED (otherwise, REOPENED bugs could just go to ASSIGNED). This would mean that nobody else than the assignee can move a bug to ASSIGNED. This is the behaviour I observed at mozilla.org's bugzilla as well.
Updating the summary to make this bug easy to search for and avoid duplicates.
Summary: "Take bug" functioanlity → "Accept bug" or "Take bug" functionality
*** Bug 25273 has been marked as a duplicate of this bug. ***
FYI - please don't ever have a REOPENED bug fo directly to Assigned. I keep metrics on how many bugs we fix per week vs. reopen. Knowing the reopen rate assist in project schedule planning.
chomp
Assignee: tara → cyeh
I'd actually like to use a minor variant of this function. I'm using Bugzilla to manage a group of people, both bug fixes and small tasks (it works quite well for that). For the task assignments, it would be convenient to enter tasks directly as ASSIGNED. An easy hack is to just change enter_bug.cgi at line 358 to add "ASSIGNED" to the pulldown, conditional on a new parameter in defparams.pl called eg. "letsubmitterchoosestatus". Would this be a general fix or is it too counter to the philosophy of Bugzilla in general?
Allan, I think that's just enough different from what's being suggested here that it should probably go in its own bug report.
See also bug 35195.
Whiteboard: 2.12
Dave: OK, thanks for the pointer to bug 35195 (it's good to see that I'm not the only one using it like this). It looks like I'm going to really need this functionality, so I'll make a "real" fix (rather than the kludge I have now) that incorporates the patch in 35195, and post a patch here after I've had a few days to shake out any problems that come up.
I have just posted a patch that will make the accept bug line change the accept buttton to change the owner to the person doing the accepting, and to change the status to assigned. I don't think that one should be able to force a bug into the assigned state, because that state indicates that one is fixing or has plans to fix that bug. When I am doing queries for bugs to fix (like for the bugzilla component), I want to see only new bugs, because the assigned bugs are already being worked on by someone else. If you want to reassign a bug, you can use the reassign bug to or the reassign bug to owner field, but there is no easy way to reassign a bug to yourself. Adding patch and approval keywords for approval escalation.
Keywords: approval, patch
I do *NOT* think the solution here is to make it so the accept button accepts for the user. Mozilla, amoung others, has a practice already in place in which the accept button does what it currently does. It might not be the best practice and you may consider it incorrect, but I believe that changing its meaning to suite your practice is not any more correct. The solution I advocate (and haven't had the round tuits to implement) is to allow this (and these) behavior(s) to be customizable.
On bugzilla.mozilla.org, I have not seen managers or similar accept bugs on behalf of others. How would the engineer look for new bugs, then? Isn't "CONFIRM" what you want? Also, nobody has the right to accept bugs on my behalf. I agree with Zach's proposal.
Provide the capability to do both, and make the wording obvious, and people will figure it out. These are the QA Contacts and Developers we're talking about here, I would assume they would have enough brains to figure out what the button does. :) As for new people installing bugzilla, the current behavior is counterintuitive, and has to be learned the hard way usually.
I'm not arguing that mozilla's practice is right or wrong, I'm just saying that mozilla has an *ESTABLISHED* practice. It would be pretty problematic if all of the sudden you see a whole lot of bugs assigned to managers on bugzilla.mozilla.org. I would argue that the mozilla people need to sign off on this before it is checked in or approved. I do think the right approach is to allow this behavior to be customized on a per-installation basis.
Seth, you say, the established practice for Mozilla were that managers accept bugs on behalf of their employees. I disagree - I have seen this rarely, if at all -, but let's assume, this were true, then to > allow this behavior to be customized on a per-installation basis would be wrong, because nobody (other than myself) can accept bugs on *my* behalf, and nobody should even have this option.
Ben: I think you are incorrect. Your established practice may be that only you can accept bugs for me. However, that is not my established practice and that is not mozilla's established practice, I believe. The fact of the matter is not YOUR practice is not more or less correct than MY practice. I'd rather that we not get into the "my way is better than your way" argument and allow both to be possible.
Seth, I don't understand your last comment.
To be clear: You being able to accept bugs on bugzilla.mozilla.org on my behalf *is* wrong. You don't have the right to do that. *If* that is a policy question, then the mozilla.org policy is "don't do that", and it should IMO be enforced by software. Zach's patch does this and also adds the feature to conviently reassign bugs to myself and accept them in one step.
Ben: First off, the policy that only the owner of the bug can transition the bug into the accepted state is not the policy for my installation of bugzilla. Second, I appologize, but I'm unfamiliar with your relationship to the mozilla project. Before saying "yeah, that's mozilla's policy", I'd like to hear from people on staff@mozilla.org, who can say "mozilla's policy is for it to work this way". If you are one of them, great. However, I have a feeling that there are people at mozilla who use the functionality as is. There is no such thing as "correctness" in a bugtracking system like this, there is only established patterns of behavior, and it is important that changes to bugzilla do not change the patterns that work, regardless of how incorrect you think they might be. I do not see why you are unwilling to accept the possibility that the way bugzilla works now is useful to some people. I'm arguing to start making these bits configurable, because *I* do use the accept button as is. In fact, if you look at the first patch attached to this bug, you'll see the change that I made, which leaves the functionality alone, but let's me make the transition to ASSIGNED and ownership change via commit. All I would like to see is for the accept bug functionality to REMAIN A POSSIBILITY FOR THOSE WHO USE IT. I do not want you to use it, and I don't care of bugzilla.mozilla.org has it (it isn't up to me, and I'm not sure if it is up to you), but I want it to be configurable enough so that you aren't making the decision for me, and I'm not making the decision for you. Grok? Feel free to take this off bugzilla and email me personally.
Seth, I think, we should make the discussion here on .mozilla.webtools, so others can follow it. No, I'm not from mozilla.org, but I am a Mozilla developer. > I do not see why you are unwilling to accept the possibility that the way > bugzilla works now is useful to some people. I do undnerstand and accept that your proposed behaviour is useful in some situations. However, it is also very problematic in some cases, and I argue that this outweights the usefulness of the way you describe. So, if we have to choose, we should IMO follow Zach's and my suggestion, at least for bugzilla.mozilla.org. So a a per-installation pref might help your installation, but would make no difference for bugzilla.mozilla.org. What would be reqired for bugzilla.mozilla.org is a complex rights hierarchy, which basically stores the management hierarchies. Above me, there is only mozilla.org, so only mozilla.org people (if at all) and I should be able to accept bugs on my behalf. Above Netscape employees, there are their managers, and they would be allowed to accept bugs on the behalf of their employees. (Is there any other situation you have in your mind?) Obviously, this is non-trival to implement. So, right now, we have to choose, and we should IMO choose Zach's suggestion, because it does IMO less harm. Can you explain *why* you want to accept bugs on the behalf of others?
Ben: Any change made to the bugzilla tree affects all users of bugzilla, not just you and not just bugzilla.mozilla.org. Making this change should not be made because you think the behavior is incorrect, but should be made by consensus of all users of bugzilla, as this is changing a fundemental behavior, that, while it is not optimial, is already in practice. A patch which lets us configure this behavior is not that much more complex and overcomes this issue. bugzilla.mozilla.org has been working this way for a very long time. Holding off for a patch which doesn't break existing practices is worth it. What about a simple change which makes two buttons, an "Accept and take bug" and an "Accept bug for existing assignee"? My installation uses the "accept-for-others" functionality to help partition bugs among developers. We use the concept of ASSIGNED as a suggestion of "I think the bug is in the code you are responsible for". I'm unwilling to debate whether or not this is a good practice. This works well for us, and that is enough.
> A patch which lets us configure this behavior is not that much more complex > and overcomes this issue. OK, then submit a patch, let's check it in, and set it to Zach's proposed behaviour for bugzilla.mozilla.org. > What about a simple change which makes two buttons, an "Accept and > take bug" and an "Accept bug for existing assignee"? You still don't seem to get me. I don't want the second option to at all exist on bugzilla.mozilla.org, at least not on bugs I own. > We use the concept of ASSIGNED as a suggestion of "I > think the bug is in the code you are responsible for". We#re talking about ACCEPT, not ASSIGN. ASSIGN is used that way in bugzilla.mozilla.org, too, but it goes into NEW, so the new owner sees that there is a bug he might not have looked at yet. ACCEPT means, "Yes, I will look into the bug" or "Yes, this is indeed my bug, and I intend to fix it" or similar. > This works well for us, and that is enough. Sure, but not, if it doesn't work for us.
Ben: I'm not claiming that you should accept my particular behavior, but I'm saying that the behavior you want excludes the behavior that *I* want. A configurable patch is ideal, and I hope to find time to write it this weekend. The behavior which the current patch implements, though, kills my group's current practice. It feels like I keep saying the same thing and you reply with the same arguement. I would like to hear from some other people. (BTW, I meant ASSIGNED in how my group works. It is too early in the morning and I've had way too little caffeine). I propose that the choices which can change the state of the bug be configurable. We have a list of state transitions and all of us want a different set to be available. *I* want a choice to reassign a bug to me, a choice to set the bug as ASSIGNED to the current owner and a choice to both REASSIGN the bug and set it as ASSIGNED to me. *YOU* want a choice to both reassign the bug to yourself and set it as assigned, but no choice to just ASSIGN the bug to the current owner. Ideally, bugzilla should be able to configure itself to do either. Would a system like that be acceptable to you? Would a system like this be acceptable to both the mozilla and bugzilla people? Hmm, maybe I'll do battle with this after lunch.
> Would a system like that be acceptable to you? Yes.
Seth, What is the purpose of a user ASSIGNING (NEW -> ASSIGN) to the current owner? I don't understand the logic behind this.
Wow. I just came back to look here. I didn't intend to start such a big discussion. However, it is certainly a NECESSITY for me to accept bugs for others, because they work for me, and I'm the one making the decisions about what they work on. I certainly understand that this isn't the way Mozilla is organized, and that's why my original suggestion was to make these features conditional on a new parameter in defparams.pl. The main goal for me is to reduce the amount of email (as it stands right now, the engineers get two pieces of email every time I submit a task for them or assign one that someone else submitted: the first piece when it gets assigned to them, and the second piece when it changes status from NEW to ASSIGNED). I'll eventually get around to implementing this, and post a patch (no promises on delivery dates).
This is going to be a long post, so bear with me here... I think the confusion here is one of ASSIGNED vs. ACCEPTED. Some sites are using ASSIGNED to mean ASSIGNED, that the person named is supposed to take care of it. Other sites are using ASSIGNED to mean ACCEPTED, that is, the person named has seen the bug and intends to work on it. What I would like to see done is to completely parameterize the entire status/ resolution system so it can be customized on each site (not just with accept vs take, but the whole thing). What would need to be done is to have a way to define what bugzilla will do with any given state. We would need to create a flowchart, if you will, that is machine readable. Here's kind of what I envision: Table "bug_states" state_now varchar(24), avail_states varchar(24) not null, privs_required tinytext, req_resolution varchar(1) not null (abbrev. below so it won't wrap), unique (state_now,avail_states) +-------------+--------------+--------------------------------+-----+ | state_now | avail_states | privs_required | r_r | +-------------+--------------+--------------------------------+-----+ | (null) | UNCONFIRMED | (null) | N | | (null) | NEW | (canconfirm|editbugs) | N | | UNCONFIRMED | NEW | (canconfirm|editbugs|owner|qa) | N | | UNCONFIRMED | ASSIGNED | (editbugs|owner|qa) | N | | UNCONFIRMED | ACCEPTED | (editbugs|owner) | N | | UNCONFIRMED | RESOLVED | (editbugs|owner|qa|reporter) | Y | | NEW | ASSIGNED | (editbugs|owner|qa) | N | | NEW | ACCEPTED | (editbugs|owner) | N | | NEW | RESOLVED | (editbugs|owner|qa|reporter) | Y | | ASSIGNED | NEW | (editbugs|owner|qa) | N | | ASSIGNED | ACCEPTED | (editbugs|owner) | N | | ASSIGNED | RESOLVED | (editbugs|owner|qa|reporter) | Y | | ACCEPTED | NEW | (editbugs|owner|qa) | N | | ACCEPTED | RESOLVED | (editbugs|owner|qa|reporter) | Y | | RESOLVED | REOPENED | (editbugs|owner|qa|reporter) | C | | RESOLVED | VERIFIED | (editbugs|qa|reporter) | K | | RESOLVED | CLOSED | (editbugs|owner|qa) | K | | REOPENED | ASSIGNED | (editbugs|owner|qa) | N | | REOPENED | ACCEPTED | (editbugs|owner) | N | | REOPENED | RESOLVED | (editbugs|owner|qa|reporter) | Y | | VERIFIED | REOPENED | (editbugs|owner|qa|reporter) | C | | VERIFIED | CLOSED | (editbugs|owner|qa) | K | +-------------+--------------+--------------------------------+-----+ The required_privs field is text to make it easy to edit. You could use parentheses, | (or), and/or & (and) to create privilege sets, so for example, you could require more than one groupset BOTH be set in order to change a particular state. You could for example, create a groupset called "managers" and add all of your management people to it, so you could then make a particular state change only allowed to be used by a manager. The req_resolution column letters would have the following meaning: N = no resolution, ignore resolution setting Y = prompt for a new resolution when making this state change K = keep the existing resolution when making this state change C = clear the resolution field when making this state change This would, of course, necessitate that the status fields be changed from enums to text fields, but I believe that's the plan these days anyway. I'm thinking it might also need an additional column to state which resolutions are available (handle it the same as avail_states - one row for each state/ resolution combination), and a column to specify if that particular state change belonged to a predefined bugzilla action (such as marking a bug as a duplicate, or moving a bug), but for space reasons (geez, this is getting long already) it's a little hard to demonstrate here. Any comments?
The ability to customize the state definitions, names, and state flow would be very good to have. You'll probably want to store off this information into some kind of static file so that you don't query the database each time you want to find out what the next state is. I'm not sure that the req_resolution field makes sense, it seems to me that there should be a better way of storing that state information in a better format. Everything else looks great.
I think there's enough discussion here that we should shelve this for 2.12 and drop it off the list. Removing 2.12 from the whiteboard.
Whiteboard: 2.12
> The required_privs field is text to make it easy to edit. Not a good reason. If you want easy edit, then build an editor. Don't adjust the database format to humans.
How would you suggest storing it then? Actually, it's text because it needs to contain more than one value, and they're not all included in the groupset. It also allows you to use things like AND and OR (&/|) and parentheses for a little better control over what combination of privs is really required.
BTW, I'm not trying to be defensive here, I was just more clearly explaining what I had in mind, and I really do want to see other ideas if anyone has any.
Dave, I have no better suggestions how to store it - I don't know Perl. Just requiring humans to edit the database is IMO a bad idea. You'd need fancy error-recovery in bugzilla, then. Also, if you have to make is it text-based, make sure to "compile" it anyhow (interpret it once during startup and cache the result), so you don't have to interpret the text for each showed bug.
Oh, I was never intending for humans to be able to edit the database directly with this. :-) Of course there will be an editor that will do error checking on the human input before storing it in the table. And since this would usually be a semi-permanent setup once it's done on a given site, I have no arguments against caching the data for easy retreval when displaying bugs. It could be added to the existing versioncache with very little effort, I'm sure.
Myk, you may be interested in this bug ;-)
(if it is ever implemented, my version of bugzilla 3.0 will have the ability described by Dave Miller on 2000-09-16 04:02)
It seems to me (sorry but this whole thing does seem a little silly), that the functionality should change so only someone who has been ASSIGNED a bug can ACCEPT a bug. Managers can assign bugs, then the coders accept and report status on them. It does not make any sense to have a button labled wrongly simply because that is how it was. It is a bug, it should be fixed. If people have missused this feature in the past it is thier concern. No one should be accepting bugs for anyone else. ASSIGNING yes, ACCEPTING no. It isn't a matter of opinion, but of how the bug process works. The MySql table stuff might be suited to another bug since it seems to address a slightly larger issue. This should have been fixed a year ago.
This is an old and annoying argument. In my bug tracking practice, I need the ability to mark a bug as accepted for someone else. i.e., to keep track of what other people are doing who don't change the bugzilla status themselves. Perhaps the button in bugzilla is mislabelled. Perhaps in YOUR INSTALLATION you would rather have different functionality. However, I don't think it is acceptable to change FUNCTIONALITY THAT IS IN USE regardless of whether or not you disagree with it. I'm much happier with the proposed system of letting the buttons and assigned functionality be based on a table and / or template. I'd rather not lose the functionality that I require.
Target Milestone: --- → Bugzilla 2.16
I figure there's no need to specify the resolution behaviour on the transition table, instead you define on the status table whether a status is open or not. Then: open -> closed = Y open -> open = N closed -> open = C closed -> closed = K I'm pretty sure that the open/closed distinction would be necessary for other things too, for example bug #24496, which asks to disallow RESOLVED FIXED when there are open bugs blocking this.
hmm, yeah, could make queries simpler, too, by allowing a pseudostatus of "OPEN" to be used which would match any open status. I'd say the same for CLOSED, but we already have a status named that.... hmm.
Well VERIFIED and CLOSED bugs are also resolved, but that doesn't help either. Maybe we should replace CLOSED with a decent regression checking system (that allows you to check it more than once) and nuke it. =)
for the way most places use it, maybe CLOSED should be RELEASED, then CLOSED can be a pseudo status that applies to RESOLVED, VERIFIED, and RELEASED.
Taking all of cyeh's Bugzilla bugs.
Assignee: Chris.Yeh → justdave
-> New product Bugzilla.
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
Whiteboard: [flow:status] [people:owner]
Blocks: 31812
Customisable statuses now lives at bug #101179.
Changing this would confuse too many people to be worth the incremental benefit. Gerv
I disagree, Gerv. It would only confuse people who are already used to it, and I would bet it doesn't confuse them for long, since the proposed way is so much more intuitive. If it helps, we could even put some instructional text right next to the new buttons to explain how they changed. There's a lot of new people using Bugzilla all the time (even on b.m.o, new people reporting bugs, new people joining the development efforts, etc). The way it is now confuses a good portion of the new people until they get trained. So the choice here is retraining all of your existing people once, or having to train all the new people every time you get someone new involved. The way it is now also confuses most of the people who set up new Bugzilla sites (just look at all the postings we keep getting to the newsgroup complaining about it). If b.m.o is *that* opposed to it, we should make it the clear way by default, but make it a param so people can have it the old way if they want, and let b.m.o set the param if they don't want to change. Although I really think b.m.o should change, too, for the reasons stated in my first paragraph.
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
See also Bug 94247 - Allow reporters to ABANDON bugs.
I strongly second Seth's comment from 2000-05-01 12:13 . It would be really helpful to have both functionalities available.
I would also really like to have both functionalities available. I think that bug 35195 (request for "and accept bug" checkbox under reassign radio button) addresses this very nicely, with a minimal addition to the UI. (An alternative would be to have a checkbox under the "accept" radio button to reassign the bug to yourself.) (Also, all of this wording will be much less confusing if/when the "ASSIGNED" status is renamed to "ACCEPTED" - bug 104049.)
*** Bug 185040 has been marked as a duplicate of this bug. ***
Attachment #8109 - Flags: review?
Attachment #14542 - Flags: review?
No longer blocks: 31812
Attachment #8109 - Flags: review?
Attachment #14542 - Flags: review?
OK, since this bug really encompases two things, which are both being handled on other bugs, I'm resolving this bug to consolidate the discussion. The "Accept bug" issue as a reassignment option is being handled on bug 35195. The "ACCEPTED" state as a separate entity from ASSIGNED is being handled on bug 101179. *** This bug has been marked as a duplicate of 35195 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
clearing target on bugs with resolution other than FIXED so they'll show up as untriaged if they get reopened.
Target Milestone: Bugzilla 2.18 → ---
Status: RESOLVED → VERIFIED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: