277672 - No way to get only deltas via whine

Status: NEW

(Bugzilla :: Whining, enhancement)

Description

[timeless]

I have large queries, and i'd like to use them for whines, but i only want to
know which bugs were new to the result list since the last time Bugzilla ran
them as queries for me for whining.

steps:
1. become a member of whining (for help, contact me)
2. edit whining
3. browse through the whining interface and see no way to get useful reports.

expected results:
1. options to:
[x] include bugs which were found in the last whine query
   [ ] display the number of consecutive times the bugs have appeared on this query.
[ ] list bugs which are non longer present in this whine query
   * bonus points for being able to list when they transitioned to "not matching
whine query"
[x] list bugs which are new to this whine query
   * bonus points for being able to list when they transitioned to "matching
whine query"

default would be [x] include previously whined, [ ] list whined items that have
dropped, [x] include new to whine list.

Comment 1

[A. Karl Kornel]

This would need some way to store the results of the last query (a new database table?).

Regardless, I think all of the options you specified could be implemented.  One question though: When 
you say "when they transitioned", do you mean (a) the date&time when the bug itself changed to make 
it match/not match the query, or (b) the date&time when whine.pl first noticed that the bug matches/no 
longer matches the query?

Comment 2

[A. Karl Kornel]

I can add the following options to each whine query:

[x] include bugs which were found in the last whine query
   [ ] display the number of consecutive times the bugs have appeared in this query.
[ ] list bugs which are non longer present in this whine query
   forget bugs no longer present after they have been mentioned in ____ emails for this whine query
[x] list bugs which are new to this whine query
<delete list of bugs found in this query> <delete list of bugs no longer present in this query>

[ ] represents a box that is not checked.  [x] represents a box that is checked.  ____ represents a text 
field.  <*****> represents a button (***** is the button text).  

The checked options above would be the defaults.  If the above options existed now, but were hidden, 
the checked boxes would be active for each whine.

At this point I do not want to work on listing when they transitioned to (whatever).  This could be 
handled some other time.

To do this, I'd create a new database table with the following schema:
whine_query_results:
    query_id: INT3  NOT NULL  (foreign key whine_queries.id enforced by sanitycheck)
    user_id: INT3  NOT NULL  (foreign key profiles.userid enforced by sanitycheck)
    bug_id: INT3  NOT NULL  (foreign key bugs.bug_id enforced by sanitycheck)
    result: INT1  NOT NULL  (see below, value enforced by sanitycheck)
    count: INT3  (see below, value enforced by sanitycheck)
    time_to_live: INT2  NOT NULL  DEFAULT='10'  (see below, value enforced by sanitycheck)
there is one index, whose fields are (query_id,user_id,bug_id) and is UNIQUE.

'result' is 0 if the bug did not appear in the results of the query when it was last executed, and is 1 is 
the bug did appear in the results.  'time_to_live' is for the "forget bugs...after they have been mentioned 
in ____ emails..." option.  It's reset when 'result' is 1.  Once this value reaches 0 the record is deleted.  
'count' is the number of consecutive times the bug has appeared in the results, and is NULL when 
'result' is 0.

When a query is deleted, all records in the table matching the query's ID are also deleted.  The same is 
true for the deletion of a bug or a user.

I can take this as soon as bug 304989 lands!