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') 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), as expected.
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.
(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.
(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') > Tony: This bug involves HW Cert. Was the hwcert code responsible for this row being added? -- simon
(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)?
(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.