Created attachment 1143392 [details] screenshot I cannot re-assign existing bugs on Red Hat Enterprise Virtualization Manager from other products. For example from Red Hat Enterprise Linux 7. How reproducible: always Try to re-assign any bug from any product to any component from Red Hat Enterprise Virtualization Manager product. Actual results: A value must be set for the 'oVirt Team' field. Please press Back and try again. During re-assign there is no field 'oVirt Team'. See screenshot.
I can not reproduce this issue, the steps I followed are: 1.Create a RHEL7 bug, 2.Change this bug to product 'Red Hat Enterprise Virtualization Manager', select a component, then save this bug. ==>This bug could moved to 'Red Hat Enterprise Virtualization Manage' successfully 3.Reassign this bug to other user, save ==>Could assign well. Could you describe your steps more detail? Thank you.
I opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1323773 Than I realised that it should be assigned on 'Red Hat Enterprise Virtualization Manager' on component: 'mingw-virt-viewer'. I was unable to do this. Bugzilla says: A value must be set for the 'oVirt Team' field.
(In reply to Rony Gong from comment #1) > I can not reproduce this issue, the steps I followed are: > 1.Create a RHEL7 bug, > 2.Change this bug to product 'Red Hat Enterprise Virtualization Manager', > select a component, then save this bug. > ==>This bug could moved to 'Red Hat Enterprise Virtualization Manage' > successfully > 3.Reassign this bug to other user, save > ==>Could assign well. > > Could you describe your steps more detail? Thank you. This CF is mandatory in production, so you need to ensure it's mandatory in the test environment.
(In reply to Jeff Fearn from comment #3) > (In reply to Rony Gong from comment #1) > > I can not reproduce this issue, the steps I followed are: > > 1.Create a RHEL7 bug, > > 2.Change this bug to product 'Red Hat Enterprise Virtualization Manager', > > select a component, then save this bug. > > ==>This bug could moved to 'Red Hat Enterprise Virtualization Manage' > > successfully > > 3.Reassign this bug to other user, save > > ==>Could assign well. > > > > Could you describe your steps more detail? Thank you. > > This CF is mandatory in production, so you need to ensure it's mandatory in > the test environment. After check the test env, it just as you said, the CF cf_ovirt_team isn't mandatory, and I don't think it should be mandatory, otherwise user must select this field when filing new bug. Anyway, it depends by the origin requester for this field.
Rony, what question are you asking me?
(In reply to Jeff Fearn from comment #5) > Rony, what question are you asking me? Do you agree that the CF cf_ovirt_team must be mandatory?
(In reply to Rony Gong from comment #6) > (In reply to Jeff Fearn from comment #5) > > Rony, what question are you asking me? > > Do you agree that the CF cf_ovirt_team must be mandatory? That is up to the CF owner. It might be reasonable to make it optional until we can support this use case if not being able to reassign bugs like this is more important than having it set. This hasn't been noticed before because, AFAICT, this is the only mandatory CF. I don't know who the CF owner is, maybe Muhammad does?.
(In reply to Jeff Fearn from comment #7) > (In reply to Rony Gong from comment #6) > > (In reply to Jeff Fearn from comment #5) > > > Rony, what question are you asking me? > > > > Do you agree that the CF cf_ovirt_team must be mandatory? > > That is up to the CF owner. > > It might be reasonable to make it optional until we can support this use > case if not being able to reassign bugs like this is more important than > having it set. > > This hasn't been noticed before because, AFAICT, this is the only mandatory > CF. > > I don't know who the CF owner is, maybe Muhammad does?. Afaik Yaniv Dary is the owner of cf_ovirt_team[1]. He should be able to clarify if the field value can be optional until we can support this use case, and if being able to reassign bugs like this is more important than having it set. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1264674
(In reply to Muhammad Tahir from comment #8) > > Afaik Yaniv Dary is the owner of cf_ovirt_team[1]. He should be able to > clarify if the field value can be optional until we can support this use > case, and if being able to reassign bugs like this is more important than > having it set. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1264674 It is very problematic for us to make it optional, since not setting ovirt_team is a considerable overhead to add later on. Any workaround for people moving bugs to RHEV?
(In reply to Yaniv Dary from comment #9) > (In reply to Muhammad Tahir from comment #8) > > > > Afaik Yaniv Dary is the owner of cf_ovirt_team[1]. He should be able to > > clarify if the field value can be optional until we can support this use > > case, and if being able to reassign bugs like this is more important than > > having it set. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1264674 > > It is very problematic for us to make it optional, since not setting > ovirt_team is a considerable overhead to add later on. Any workaround for > people moving bugs to RHEV? AIUI there is no work around besides making it optional; there is no ability to add CFs not visible to the current product. I've set the things required to get this done and pushed as a hot fix, it will be up to the PO to approve that.
Hi. Any updates? I was asked to re-assign a bug from RHEL to RHEVM. I cannot do it not.
Perhaps someone can go and edit the database for bug 1345864 to assign it to RHEV-M / ovirt-engine. In the mean time, setting this bug as a dependency.
You can work around this by doing a bulk update. 1: go to bug 1345864 2: click "Show other bugs" link to bring up a search 3: click "Change Several Bugs at Once" link 4: click check box for bug 1345864 5: change product 6: change oVirt Team CF to the required value 7: click "Commit" 8: ??? 9: profit It' been years since I've done a ??? profit list, please forgive any errors in format :D
Please reconsider this for the next upgrade.
Still not fixed!
Please note the bugzilla-5.x flag, this bug will not be considered for scheduling until after bugzilla 5 has shipped.
If this 'ovirt team' field is the only such field, maybe it could be made non-mandatory while waiting for bugzilla 5 to ship. People outside the ovirt team are not likely to have a clue to what to set it to anyway.
*** Bug 1484314 has been marked as a duplicate of this bug. ***
(In reply to Yaniv Lavi (Dary) from comment #9) > It is very problematic for us to make it optional, since not setting > ovirt_team is a considerable overhead to add later on. Then what about using a bugzilla bot to detect cases where the field is not set, so it can be made optional, and allow bug reassigning? I've lost count of the bugs initially filed to libguestfs that were actually bugs in oVirt, and the only way to move them was to create new bugs, and close the old ones.
(In reply to Pino Toscano from comment #21) > (In reply to Yaniv Lavi (Dary) from comment #9) > > It is very problematic for us to make it optional, since not setting > > ovirt_team is a considerable overhead to add later on. > > Then what about using a bugzilla bot to detect cases where the field is not > set, so it can be made optional, and allow bug reassigning? I aggree. A bot could set needinfo to the person who performed the change of product. Yaniv, would that be acceptable solution until this is properly fixed?
(In reply to Tomáš Golembiovský from comment #22) > (In reply to Pino Toscano from comment #21) > > (In reply to Yaniv Lavi (Dary) from comment #9) > > > It is very problematic for us to make it optional, since not setting > > > ovirt_team is a considerable overhead to add later on. > > > > Then what about using a bugzilla bot to detect cases where the field is not > > set, so it can be made optional, and allow bug reassigning? > > I aggree. A bot could set needinfo to the person who performed the change of > product. Yaniv, would that be acceptable solution until this is properly > fixed? No, this is not. I will incur considerable overhead on the entire RHV/oVirt team. We must have this team set by the reporter when opening the bug.
(In reply to Yaniv Lavi (Dary) from comment #23) > (In reply to Tomáš Golembiovský from comment #22) > > (In reply to Pino Toscano from comment #21) > > > (In reply to Yaniv Lavi (Dary) from comment #9) > > > > It is very problematic for us to make it optional, since not setting > > > > ovirt_team is a considerable overhead to add later on. > > > > > > Then what about using a bugzilla bot to detect cases where the field is not > > > set, so it can be made optional, and allow bug reassigning? > > > > I aggree. A bot could set needinfo to the person who performed the change of > > product. Yaniv, would that be acceptable solution until this is properly > > fixed? > > No, this is not. I will incur considerable overhead on the entire RHV/oVirt > team. > We must have this team set by the reporter when opening the bug. Sure -- then let's leave the field mandatory when *opening* a new bug, but optional when *reassigning* an existing one. This way, new bugs are still properly categorized, while reassigned ones (which I can imagine to not be many) will need adjustment. I understand that this helps the work of the oVirt team, but this is making work of other people (and even some oVirt people, i.e. those triaging/helping related products, such as libguestfs) way more troublesome than needed.
As someone not deeply involved with oVirt, I usually have no clue which team to assign a bug I'm opening or reassigning, so someone who knows will have to go over this field anyway. Mandating it just makes it harder to get people to report bugs against your product.
(In reply to Christophe Fergeau from comment #25) > As someone not deeply involved with oVirt, I usually have no clue which team > to assign a bug I'm opening or reassigning, so someone who knows will have > to go over this field anyway. Mandating it just makes it harder to get > people to report bugs against your product. This is why we have a detailed and updated help for this field.
Mandatory CF is now available for setting on product change confirmation page.
This bug has been resolved in Red Hat Bugzilla 5 and can be tested on https://beta-bugzilla.redhat.com If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.
I still can't reassign a bug to RHEV-M (2 years and counting), and beta-bugzilla doesn't work for me.
(In reply to Richard W.M. Jones from comment #29) > I still can't reassign a bug to RHEV-M (2 years and counting), and beta-bugzilla doesn't work for me. Here is a change I just did to move this very bug on beta to RHEV-M. https://beta-bugzilla.redhat.com/show_bug.cgi?id=1323778#h33 You might want to open a bug about your not being able to use the beta, or mail the internal bugzilla devel list. The upgrade is tentatively planned for July so you'll want that addressed before production doesn't work for you either.
It seems that beta-bugzilla has only a partial view of the bug database, cf: https://beta-bugzilla.redhat.com/show_bug.cgi?id=1583641 - "missing bug ID" https://bugzilla.redhat.com/show_bug.cgi?id=1583641 - shows the bug
beta-bugzilla is running against a copy of the database made at some date in the past. It is refreshed from time to time. bug 1583641 was created after that copy was made.
STILL can't reassign bugs to oVirt. Can't we just fix this some time in the actually running Bugzilla?
(In reply to Richard W.M. Jones from comment #33) > STILL can't reassign bugs to oVirt. Can't we just fix this some time > in the actually running Bugzilla? Perhaps the previous answers to this this question weren't suitably definitive. We will not be back porting this fix to Bugzilla 4, period.