300126 - Support user defined workflow triggers based on request criteria

Status: NEW

(Bugzilla :: Attachments & Requests, enhancement)

Description

[timeless]

overall concept:
what would it take to get bugzilla to support user defined triggers?
like "if someone marks flag+, set flag2?"

the triggers would have to be flagged by the user who defines them, the same way
they request a normal flag.

steps:
1. timeless defines rule [name] "timeless-1":
[condition] when
review+(matchbyname) and
superreview+(matchbyname) and
approval10[is not set](matchbyname)
[x] _set_ approval10?(matchbyname)
[x] send email
 [x] allow watchers to receive mail (* watchers will not receive mail if they
can not see the bug or attachment or flags)
[show for] products:all
bonus points: [x] display trigger to other users when it is selected

2. timeless edits an attachment (#100023) and checks review?, superreview?,
timeless-1+
3. lpsolit marks review+ (being in grant group for review+)
4. neil marks superreview+ (being in grant group for superreview+)
5. timeless-1 tries to trigger
it sees that timeless is in request group for approval10 and sets
timeless:approval10?
6. an email is sent to timeless and any watchers (who haven't opted out of
trigger mail)

about "matchbyname" this is to tolerate the fact that for product--all-- there
are a bunch of flags named "review" and it's ok for any of them to match.

the opposite of "matchbyname" is "matchbyid" which will let you specify a flag
and stick to the flag even if the flag changes names.

Comment 1

[William Gallafent]

As per discussion in bug 475409 , a more general (not just flags) way to achieve this /in a site-wide manner/ would be very useful (and could fix the workflow regression of that bug) to me.

Since it provides a nice example, here is some more detail of the particular type of trigger which would solve that bug:

Detect a change in the “Assigned To” field.
Trigger a consequent change in the “Status” field, according to rules such as:

[new default lifecycle]
IN_PROGRESS -> CONFIRMED (if bug was ever confirmed)
IN_PROGRESS -> UNCONFIRMED (if bug had for example previously changed directly from UNCONFIRMED to IN_PROGRESS)

[old lifecycle]
ASSIGNED -> NEW (if bug was ever confirmed)
ASSIGNED -> UNCONFIRMED (if bug was assigned without ever being confirmed)

(I'd add some more for our custom workflow of course :)