Bug 844677 - needinfo activity issues
needinfo activity issues
Status: CLOSED NEXTRELEASE
Product: Bugzilla
Classification: Community
Component: Database (Show other bugs)
4.2
Unspecified Unspecified
unspecified Severity medium (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
:
Depends On:
Blocks: 849161
  Show dependency treegraph
 
Reported: 2012-07-31 07:32 EDT by Chris Ward
Modified: 2013-06-23 21:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 849161 (view as bug list)
Environment:
Last Closed: 2012-09-09 22:47:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Ward 2012-07-31 07:32:12 EDT
Description of problem:

https://bugzilla.redhat.com/show_bug.cgi?id=841116
https://bugzilla.redhat.com/show_activity.cgi?id=841116

In the activity of this bug, you can see 

WHEN: 2012-07-23 21:56:46 EDT	
ADDED: needinfo?272338


First off, 272338 should be that profile id's login_name ('myamazak@redhat.com')

There seems to be a bug somewhere causing the id to not be converted to login_name, since there are quite a few cases (hundreds) where this is happening. tail(..., 843405, 843400, 843725)

We can see later, in bug 841116, REMOVED: needinfo?(myamazak@redhat.com),
as expected.
Comment 1 Chris Ward 2012-07-31 07:45:25 EDT
While we're at flags... 

https://bugzilla.redhat.com/show_activity.cgi?id=516548

Notice the first event was ADDED: avalon-pm_ack?
There was never any event that removed avalon-pm_ack?, but yet, that flag is not currently set. Again, there are hundreds of bugs affected like this. 

I would expect that *no* change to field values should occur without activity log being updated.
Comment 2 Simon Green 2012-09-07 07:46:56 EDT
(In reply to comment #1)
> While we're at flags... 
> 
> https://bugzilla.redhat.com/show_activity.cgi?id=516548
> 
> Notice the first event was ADDED: avalon-pm_ack?
> There was never any event that removed avalon-pm_ack?, but yet, that flag is
> not currently set. Again, there are hundreds of bugs affected like this. 
> 
> I would expect that *no* change to field values should occur without
> activity log being updated.

The flag hasn't been removed, it has been made inactive. Changes to the attribute of flag types (including deleting a flag type) are not reflected in the bug history.
Comment 3 Simon Green 2012-09-07 07:48:17 EDT
(In reply to comment #0)
> Description of problem:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=841116
> https://bugzilla.redhat.com/show_activity.cgi?id=841116
> 
> In the activity of this bug, you can see 
> 
> WHEN: 2012-07-23 21:56:46 EDT	
> ADDED: needinfo?272338
> 
> 
> First off, 272338 should be that profile id's login_name
> ('myamazak@redhat.com')
> 

Tony: This bug involves HW Cert. Was the hwcert code responsible for this row being added?

  -- simon
Comment 4 Chris Ward 2012-09-07 10:26:26 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > While we're at flags... 
> > 
> > https://bugzilla.redhat.com/show_activity.cgi?id=516548
> > 
> > Notice the first event was ADDED: avalon-pm_ack?
> > There was never any event that removed avalon-pm_ack?, but yet, that flag is
> > not currently set. Again, there are hundreds of bugs affected like this. 
> > 
> > I would expect that *no* change to field values should occur without
> > activity log being updated.
> 
> The flag hasn't been removed, it has been made inactive. Changes to the
> attribute of flag types (including deleting a flag type) are not reflected
> in the bug history.

What does it mean 'inactive'? I mean, technically speaking, what happens when a flag is set to 'inactive'?

If there is activity history for a particular id.field but one can not align that with the current value of that id.field, historical lookups get much more difficult.

I mean, I suppose this specific flag was deemed as garbage, so we can completely ignore it in this case. But in the future, we might still have use for old, 'inactive' flags (and other field data) so i think it's extremely important that when data is dropped, an activity event should indicate it or ALL the historical data should be removed along with it's deactivation. Dot our i's and cross our t's, you know. :)

Is there any benefit in not tracking a 'remove' event when something is disabled (ie, removed)?
Comment 6 Simon Green 2012-09-09 22:54:25 EDT
(In reply to comment #4)
> What does it mean 'inactive'? I mean, technically speaking, what happens
> when a flag is set to 'inactive'?

An inactive flag means it is not displayed on the screen, but it can still be searched on.

> Is there any benefit in not tracking a 'remove' event when something is
> disabled (ie, removed)?

No. bugs_activity tracks changes to the bugs, not to other things (e.g. renaming a product, version or component)

Marked as CLOSED/NEXTRELEASE for tfu's change.

Note You need to log in before you can comment on or make changes to this bug.