Comment 8 for bug 720147

On 28 April 2011 16:12, Gavin Panella <email address hidden> wrote:
>> It could be this or it could be the transitionToStatus() call that's
>> doing the notification.
>
> I'm reasonably sure that transitionToStatus() does not notify().
>
> Instead I think a view takes care of firing an ObjectModifiedEvent
> (once all changes have been applied), and the web service machinery
> does the same for API calls over the wire.

Yeah, transitionToStatus() isn't the source.

>>> 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.
>
> I think it might be a bad idea to bypass transitionToStatus() because
> it does a *lot* more than set the bug's status. It's probably true of
> all the transitionTo*() methods.
>

I thought the same, so I've tried using transitionTo*() in createBug()
and it seems not to have broken anything. I think its existence in the
view is due purely to hysterical raisins and our old "don't do
security checks in the model" rule, which went out when the API
arrived.