Open Bug 278455 (bz-field-watch) Opened 20 years ago Updated 4 years ago

Ability to "watch" based on any field

Categories

(Bugzilla :: Email Notifications, enhancement, P1)

Product:
Bugzilla
Component:
Email Notifications
Version:
2.19.1
Type:
enhancement

Tracking

()

People

(Reporter: mkanat, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: student-project, Whiteboard: [roadmap: 4.0])

Attachments

(1 file)

Work In Progress
7.41 KB, patch
Details | Diff | Splinter Review 
It would be nice to be able to "watch" bugs based on *any* bug field available
in fielddefs.

I actually think this would be pretty easy to code. (Or at least, easier than
one might expect.)

UI
--
       ------------------         ---------------
Field: |            | v |  Value: |             |
       ------------------         ---------------

Basically, you just pick the field, and what value you want it to have. The
field listings come from fielddefs, and the value is just typed-in by the user.
It would get its own page, probably, in the User Preferences. It would also show
what fields/values you're currently watching, and allow you to delete the watch.

Implementation
--------------

Also pretty easy. It would just be a big OR statement in the WHERE clause
against the profiles_watching table. (Which is what I'm preliminarily calling
this table.) It just sees who's watching what fields of the bug.

profiles_watching has three columns: user_id, fieldid, value. In the case of
enumerated fields (like "product" or "component") it will be the id of the value.

We would need to add two columns to fielddefs which note where the "valid
values" for that field are stored. For example, for the "product" field, the
"value_displayed" column would be "products.name" and the "value" column would
be "products.id".
Depends on: 278458
I agree that this would be VERY handy, but it may also cause concerns about the
process_bug processing times.

I'm CCing myk since we should get hime involved in this early.
(In reply to comment #1)
> I agree that this would be VERY handy, but it may also cause concerns about the
> process_bug processing times.

  Right. I was definitely considering that. I think, though, that it would be
easy as long as we had the right indexes on the profiles_watching table. We'd
load everything into a big "watchers" hash from one SQL statement, and it
wouldn't even be all that much data we'd be returning.
Blocks: 14137
Blocks: bz-component-watch, 95255
It's a good idea so long as it can be performant enough.
(In reply to comment #3)
> It's a good idea so long as it can be performant enough.

If the general approach is not performant enough, I would apprechiate very much
if at least the special case described as Bug 76794 could be done.


I plan to work on this for 2.22, if nobody gets to it before me.
Target Milestone: --- → Bugzilla 2.22
Assignee: email-notifications → mkanat
Priority: -- → P3
No longer blocks: bz-component-watch
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
Priority: P3 → P2
Attached patch Work In Progress — — Splinter Review 
This is a very, very broken work-in-progress.

Actually, I've tested it, and technically all the code *works*... but Bugzilla needs some serious re-architecture around fielddefs before this can actually land Also, the patch as it exists doesn't actually *work* -- only the various parts of it "work," in incomplete ways.

This should give a general idea of how the solution will be architected, though.
Whiteboard: [roadmap: 3.2]
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Priority: P2 → P1
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Whiteboard: [roadmap: 3.2] → [roadmap: 4.0]
Max,

Re: bug 418301 - I agree that this solution *could* work if it included the ability to do both all base logic types (AND, OR, XOR, and NOT).  The problem I see with this is when a notification list is very long, it can take a significant amount of time to send emails.  That means a user must "hang in there" longer for the "bug updated" message.

A challenge I see in light of this bug (278455) is usability - how does one display the logic tree and how does one tell the system to send email when a value changes to or from another value versus when a value remains in a given state...  I must assume that allowing users to do this would have to be a configuration parameter as large installations would probably want to turn this off or keep the number of allowable limitations per-user to a reasonable minimum.

I also (wondering out loud) am considering - "How do I tell users how to utilize this method versus the method I proposed in bug 418301?" because it seems that this method will require users to be more Bugzilla-savvy.  That's not a bad thing, it just seems that the learning curve will be steeper.

Kevin

(In reply to comment #10)
> Re: bug 418301 - I agree that this solution *could* work if it included the
> ability to do both all base logic types (AND, OR, XOR, and NOT).

  It would included none of those in this bug. In a later bug it would include AND only. That handles every known use case.

> The problem I
> see with this is when a notification list is very long, it can take a
> significant amount of time to send emails.

  That is a completely separate problem, handled in bug 284184.

> A challenge I see in light of this bug (278455) is usability - how does one
> display the logic tree 

  Very simply, as I described in comment 0. Any details about AND should be discussed in a separate bug.

> and how does one tell the system to send email when a
> value changes to or from another value versus when a value remains in a given
> state... 

  You wouldn't; that feature would not be implemented.

> I must assume that allowing users to do this would have to be a
> configuration parameter 

  Nope, as with bug 284184 it's not a performance issue.

> I also (wondering out loud) am considering - "How do I tell users how to
> utilize this method versus the method I proposed in bug 418301?" because it
> seems that this method will require users to be more Bugzilla-savvy.  That's
> not a bad thing, it just seems that the learning curve will be steeper.

  I think it'll be more intuitive for them, because they'll think, "Hrm, I want to get notified of all bugs in Product X. Oh, okay, I just say, 'Product' 'X' here." There will be some small instructions on the page about it.
(In reply to comment #11)
> > and how does one tell the system to send email when a
> > value changes to or from another value versus when a value remains in a given
> > state... 
> 
>   You wouldn't; that feature would not be implemented.

  To be clear here, "leaving the state", "coming into the state", and "being in the state" would all be considered "being in the state."
(In reply to comment #12)
>   To be clear here, "leaving the state", "coming into the state", and "being in
> the state" would all be considered "being in the state."

  Though in some future bug we could implement "changes to" vs "is" if somebody can give us a use case important enough to justify the implementation effort. For performance reasons we can't implement the whole Boolean Chart Search.pm system, though.
(In reply to comment #11)
> (In reply to comment #10)
> > Re: bug 418301 - I agree that this solution *could* work if it included the
> > ability to do both all base logic types (AND, OR, XOR, and NOT).
> 
>   It would included none of those in this bug. In a later bug it would include
> AND only. That handles every known use case.

OR combined with AND handles every known use case?  What about NOT?

>   Very simply, as I described in comment 0. Any details about AND should be
> discussed in a separate bug.

Okay - will do

> > and how does one tell the system to send email when a
> > value changes to or from another value versus when a value remains in a given
> > state... 
> 
>   You wouldn't; that feature would not be implemented.

That's part of what I tried to address in the table.  There is a need for it.  I guess it'll be another customization. :-/

IMHO large part of this functionality does not really belong to Bugzilla.

"When someone is swearing, others do not shut his mouth, but their own ears"

Bugzilla 'just like Unix utility' should do a simple task: notify on ANY change within configured fields.  No explicit conditions, all changes are OR'ed.

It will take one SELECT to figure out a list of users to be notified.  Will generate more emails, but do it simple.

The rest belong to userspace: filter Bugzilla notifications to taste.  Headers like 'X-Bugzilla-Changed-Fields:' would assist with the task to procmail users, and coherent body syntax will do the same for, say, Outlook people.
(In reply to comment #15)
> IMHO large part of this functionality does not really belong to Bugzilla.
> 
> "When someone is swearing, others do not shut his mouth, but their own ears"

That just doesn't fly with me.  If my child is swearing at me, then it's my job to guide my child to better behavior.  Bugzilla is still in development and just because it can spam users doesn't mean we should continue to let it limp along at that level of performance.  We can teach it to do better so it isn't "swearing" (as you put it) at others when they don't want to hear it.

> The rest belong to userspace: filter Bugzilla notifications to taste.  Headers
> like 'X-Bugzilla-Changed-Fields:' would assist with the task to procmail users,
> and coherent body syntax will do the same for, say, Outlook people.

Just because you don't want the functionality doesn't mean that there aren't others that do.  Filtering on X-* in Outlook requires VB to be reliable due to the limitations of rules processing within Outlook.

My experience has been that engineers like myself get on the order of hundreds of emails a day.  Anything I can do to help reduce the number of unnecessary emails helps make engineers more effective.  If a group of 40 engineers spends an hour a week dealing with unwanted emails, eliminating those emails is like getting another engineer for free!
Assignee: mkanat → email-notifications
Keywords: student-project
Alias: bz-field-watch
Blocks: 576340
See Also: → bz-component-watch
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---
Oops! I meant to put my last comment under the previous ticket I was viewing. If an Admin can delete it and this comment, please do.
No longer blocks: 95255
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: