|Summary:||RFE: Support different bug status workflows based on product|
|Product:||[Community] Bugzilla||Reporter:||David Lawrence <dkl>|
|Component:||Administration||Assignee:||Max Kanat-Alexander <mkanat>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-06-01 20:31:53 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description David Lawrence 2010-05-04 20:50:54 UTC
Based on JIRA Requirements 3.11, we need to be able to configure some custom workflow features based on Bugzilla product. One of the workflow configurations currently supported by JIRA is to be able to dictate the state flow for issues assigned to specific projects. Currently Bugzilla does support some form of state workflow but it is global and would effect all products in Bugzilla. The workflow for Fedora or RHEL may not be suitable for JBoss products, etc. It would be beneficial to the JIRA migration if the state workflow could be configured on the product level. If a custom workflow is not enabled for a particular product then it would fall back to the default workflow similar to what we have today. Additionally when we have workflows per product, the triggers that can be configured for certain state changes would also need to be customizable per product as well.
Comment 1 Max Kanat-Alexander 2010-05-26 21:38:27 UTC
Okay. I strongly recommend against having per-product workflows, because it will make query.cgi complicated and hard-to-understand for users who only use one or two products (which is most users). The Red Hat Bugzilla workflow is already hard for me to understand as a community contributor--having it be different for every product would make it basically hopeless. One possible solution is to *simplify* the existing workflow until it applies to all projects, and use other features of Bugzilla (perhaps as part of the custom workflow system in bug 584938) to implement the more complex aspects of the existing status workflow.
Comment 2 David Lawrence 2010-05-27 21:14:55 UTC
(In reply to comment #1) > Okay. I strongly recommend against having per-product workflows, because it > will make query.cgi complicated and hard-to-understand for users who only use > one or two products (which is most users). The Red Hat Bugzilla workflow is > already hard for me to understand as a community contributor--having it be > different for every product would make it basically hopeless. Can you elaborate on the point that it would make query.cgi more difficult? Wouldn't it still just show all bug states in the status list and allow people to query for bugs in a particular state at the current time? I don't think we need the query.cgi page to filter down the states based on which product is selected. If a user selects a product and a state that the product is not enabled for, those bugs would just not display in the list. What we are looking for is a way to determine which states a bug can transition to based on it's current state and it's product and only display those states in the bug status drop down in show_bug.cgi. This is done currently with the stock Bugzilla code but it is global for all products. For example RHEL has a state flow diagram that is different that what other Bugzilla projects needs so at the current time we can just educate the RHEL engineers on which states they should be using and ignore the rest since Bugzilla shows all states. We have all transitions enabled so that other products can follow whichever workflow they desire. If we were able to configure it per product, Fedora for example would be able to dictate their own status workflow. If we do go this route the Bugzilla code would need to throw an error if the user is changing product and the current state or new state is not valid for the new product and show possible choices. > One possible solution is to *simplify* the existing workflow until it applies > to all projects, and use other features of Bugzilla (perhaps as part of the > custom workflow system in bug 584938) to implement the more complex aspects of > the existing status workflow. Yes this would be another possibility using extensions (check_can_change_field) to filter the states based on code that is hard coded to look for specific products and the user's role. But we would like to get away from hard coding product names, etc. in extension code and have some way to configure this through a UI. I thought making editworkflow.cgi be configured per product would be a simple first step and then add ways to add additional triggers on top of that.
Comment 3 Max Kanat-Alexander 2010-05-27 21:23:55 UTC
Okay, so let's pretend like I am a Fedora developer, and the only workflow I care about is: NEW ASSIGNED CLOSED Then let's say that there's another person who's a RHEL engineer, and all they care about is (making this up): NEW MODIFIED ON_DEV ON_QA CLOSED Now let's pretend like I am a Fedora contributor (not a developer) who knows absolutely nothing about Bugzilla, RHEL, or Red Hat's statuses. What statuses do I search for? What happens when there are 10 different products with *entirely different* status workflows, and there are 25 statuses in the query.cgi "Status" search box? What I meant about simplifying the workflow was not about adding extensions--it was that perhaps the Status field is being given too much meaning on bugzilla.redhat.com, and that other features of Bugzilla, like flags, should be being used for some of those meanings. Then you could have a three-or-four state workflow that applied to all products and wouldn't need to be customized per-product.
Comment 4 David Lawrence 2010-06-01 20:31:53 UTC
(In reply to comment #3) > Okay, so let's pretend like I am a Fedora developer, and the only workflow I > care about is: > > NEW > ASSIGNED > CLOSED > > Then let's say that there's another person who's a RHEL engineer, and all they > care about is (making this up): > > NEW > MODIFIED > ON_DEV > ON_QA > CLOSED > > Now let's pretend like I am a Fedora contributor (not a developer) who knows > absolutely nothing about Bugzilla, RHEL, or Red Hat's statuses. What statuses > do I search for? What happens when there are 10 different products with > *entirely different* status workflows, and there are 25 statuses in the > query.cgi "Status" search box? > > > What I meant about simplifying the workflow was not about adding extensions--it > was that perhaps the Status field is being given too much meaning on > bugzilla.redhat.com, and that other features of Bugzilla, like flags, should be > being used for some of those meanings. Then you could have a three-or-four > state workflow that applied to all products and wouldn't need to be customized > per-product. Ok, I have thought about this some more and feel that we do not need to go this route then for now. I think we can keep the workflow wide open as we do now and use extensions to look at other criteria (keywords, flags, etc.) to help dictate workflow that can be configured independently for each product. This is the focus of the parent group of this bug. Currently for RHEL products we use something called the three ack process. We have various NVR flags such as rhel-5.6.0, rhel-6.0.0, rhel-6.1.0. Each bug gets one of these flags set to help dictate which release the bug is slated for. This flag is initially set to '?'. We then have three other 'ack' flags, pm_ack, devel_ack, and qa_ack. They are all set to '?' automatically by a third party application we wrote in-house called 'bugbot'. It basically queries bugzilla via XMLRPC every 10 minutes running through a series of Rules that look for bugs that match a specific criteria. And then sets the flags as needed to help the process along. Then a human from each of the three departments (qa, devel, product management) sets their related flag to '+' if they can handle the bug for the upcoming release. Once all three 'ack' flags are set to '+', the bugbot automatically sets the NVR flag to '+' and the bug will be handled in the release. If any one of the ack flags are set to '-', the bug is closed as WONTFIX with a comment but the bugbot. Eventually we would like all of this to be handled internally to Bugzilla so it happens more realtime and not by a third party application. Also it would be nice if Bugzilla understood the rules that bugbot follows in it's config file and did not allow certain changes to occur unless certain conditions are already met (check_can_change_field would need to understand flags settings). But I admit that alot of this can be done via extensions and that is where we need the most focus for the JIRA requirements for now. Dave