| |
@@ -134,9 +134,11 @@
|
| |
if lowest_status_update.status == 'stable':
|
| |
if bug.status in ['MODIFIED', 'ON_QA', 'VERIFIED', 'CLOSED']:
|
| |
label.append('<span class="radius success label">')
|
| |
- if lowest_status_update.pending:
|
| |
- label.append('pending ')
|
| |
- label.append('stable</span>')
|
| |
+ else:
|
| |
+ label.append('<span class="radius label">')
|
| |
+ if lowest_status_update.pending:
|
| |
+ label.append('pending ')
|
| |
+ label.append('stable</span>')
|
| |
|
| |
elif lowest_status_update.status == 'testing':
|
| |
label.append('<span class="radius alert label">')
|
| |
adamwill
commented 5 years ago
This logic has a hole in it: when the 'lowest_status_update' is
stable but the bug is not MODIFIED, ON_QA, VERIFIED or CLOSED,
no label text is generated at all, because the line that appends
'stable' to the text is inside the
if bug.status in...conditional.
This seems like an odd case, but it does in fact happen from
time to time. Our current case of it is bug #1683197 and update
FEDORA-2019-82fd459dae; the update is marked as related to the
bug, and it really did fix the bug in one configuration (UEFI
systems), so it would be wrong to mark the update as not related
to the bug. But it did not fix the bug in another case (BIOS
systems), so it would be wrong for the bug to be closed. Thus we
need blockerbugs to handle this.
The fix is simple - just move the line that appends 'stable' up
one level of indentation so it always happens when the update is
stable, regardless of bug status. We also do this for the line
that adds 'pending ', since that's just the same situation, we
should also do that regardless of the bug status. We also have
to handle the span tag; for the case where the bug isn't in one
of the 'looks like this is fixed' states, I just went with
'radius label' as the class. Note these classes aren't currently
working due to a separate bug, I will send a separate PR for
that.
Fixes: #82
Signed-off-by: Adam Williamson awilliam@redhat.com