Comment 6 for bug 720147

On 28 April 2011 09:49, Gavin Panella <email address hidden> wrote:
> I think the problem lies in FileBugViewBase.submit_bug_action:
>
>         self.added_bug = bug = context.createBug(params)
>
>         # Apply any extra options given by a bug supervisor.
>         bugtask = self.added_bug.default_bugtask
>         if 'assignee' in data:
>             bugtask.transitionToAssignee(data['assignee'])
>         if 'status' in data:
>             bugtask.transitionToStatus(data['status'], self.user)
>         if 'importance' in data:
>             bugtask.transitionToImportance(data['importance'], self.user)

This is exactly the same conclusion as I've come to this morning.

> The call to context.createBug(...) fires an ObjectCreatedEvent, which
> is probably where notifications to subscribers are sent... *before*
> the status is updated.

It could be this or it could be the transitionToStatus() call that's
doing the notification. Remember that until the BugTask's status is
set to TRIAGED it actually meets your criteria for the "Triage"
filter. I'm not wholly sure if that means that we'll send you an email
about it when it gets changed from NEW to TRIAGED, but it kind of
makes sense to do that in every situation but this one (because the
bug was in the set of "I generally want to know about this" and you
may need to still know about it after it drops out of that general
set).

> Now, status can be set on the CreateBugParams object that is passed
> into createBug(), but not importance for example, so a general fix is
> not possible down that road without adding more to CreateBugParams.
>
> A general fix might involve delaying the notification of the
> ObjectCreatedEvent within createBug(). createBugWithoutTarget() is an
> example of how a similar problem has been solved in the past.

Right. I'm broadly more in favour of fixing CreateBugParams to accept
more options than futzing around with when notify() happens and which
method's responsible for it. In fact I think that change might be
(relatively) simple, so I'm going to give it a shot now and see what
breaks (and also see if it fixes the problem).

Now, if the notification is actually the one being sent out by
transitionToStatus() then no amount of changing CreateBugParams is
going to help. In that case I don't think there's a simple solution to
this problem (at least not one that I can tackle in what remains of
today) so I'll settle for just changing the wording on the overlay for
the time being to make things a bit clearer.