Solution: We used a mapping table of JIRA type to Bugzilla keywords. Although this could be done in a new custom field now instead with the move to BZ 3.4 Solution: We will go for custom field/drop down with data validation
- dkl - Bugzilla has a single issue type but attributes such as Keywords can be used to represent other types
- max - So it does not support setting up different workflows dependent on type
- kab - What are the custom workflows per product per type?
And how should/could they be translated to bugzilla?
- What interface does JIRA use to create custom workflows? - What is the percentage breakdown of types? piechart.
- What is the percentage breakdown of customised workflows?
- Are keywords an acceptable alternative?
- dkl - Can you explain more what a sample workflow for specific Type?
What type of actions are done such as assigning to specific user or group of users? sanity checks the data
The type field will be copied over with the next migration.
The issue type field now copied over from Jira (starting with today's import).
I talked to ldimaggi and ccrouch this week regarding workflow changes based on issue type. We can discuss this further in today's conference call.
Marking as ONQA pending discussions from the conference call.
At the conference call, we decided that the workflow for patches will be the same as the workflow for bugs. Therefore there are no additional changes required for this bug.
I will create a new bug shortly so that the 'Type' field appears on the bug creation page.
Clean-up task from the March 9 2011 Bugzilla / BRMS Pilot Meeting
This bugzilla has been marked as ON_QA - we need to verify that the changes made to https://bz-web2-test.devel.redhat.com/ are acceptable and that this bugzilla can be closed. Please verify the change and close (or re-open) this bugzilla by March 15 2011. Thx!
Verifying by BRMS-535 and BRMS-519.