View Issue Details

IDProjectCategoryView StatusLast Update
0013498mantisbtapi soappublic2019-06-18 06:46
Reporterpwillia6 Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status acknowledgedResolutionopen 
Product Version1.2.5 
Summary0013498: EVENT_REPORT_BUG not raised via SOAP API
Description

The event is coded into the user update code not the core api code. It should be raised whenever a new event is created not just via the HTML interface.

Steps To Reproduce
  1. Create a plugin with a hook for EVENT_REPORT_BUG.
  2. Raise an event via the SOAP API - observe that the hook is not called.
Additional Information

Recommended change:

Remove:

 # Allow plugins to post-process bug data with the new bug ID
 event_signal( 'EVENT_REPORT_BUG', array( $t_bug_data, $t_bug_id ) );

from bug_report.php

Add:

   # Allow plugins to post-process bug data with the new bug ID
   event_signal( 'EVENT_REPORT_BUG', array( $this, $this->id ) );

To end of function create in core/bug_api.php

TagsNo tags attached.

Relationships

has duplicate 0015235 closedrombert Reporting an issue via the SOAP API does not trigger event EVENT_REPORT_BUG 
related to 0020578 new move some events into core API 
child of 0011993 acknowledged trigger events when bug added etc via soap 

Activities

atrol

atrol

2011-11-09 03:43

developer   ~0030204

I think it's the right decision to move the code, but there will be problems with existing plugins.

What will happen if a plugin like timecard [1] is installed and a bug is created via SOAP API?
Not all plugins might be able to handle the situation that they are not called from a form in browser.
I think this [2] works for timecard, but probably there are other scenarios where plugin developers are not aware that their functions are called via SOAP.

Maybe there are other plugins which generate HTML output when hooking EVENT_REPORT_BUG, ....

Another side effect I found: After the suggested change the EmailReporting Plugin [3] will signal two times EVENT_REPORT_BUG

[1] https://github.com/mantisbt-plugins/timecard/blob/master/Timecard/Timecard.php#L60
[2] https://github.com/mantisbt-plugins/timecard/blob/master/Timecard/Timecard.php#L124
[3] https://github.com/mantisbt-plugins/EmailReporting/blob/master/core/mail_api.php#L807

rombert

rombert

2011-11-09 03:56

reporter   ~0030205

(In reply to comment 0013498:0030204)

I think it's the right decision to move the code, but there will be problems
with existing plugins.

What will happen if a plugin like timecard [1] is installed and a bug is created
via SOAP API?
Not all plugins might be able to handle the situation that they are not called
from a form in browser.
I think this [2] works for timecard, but probably there are other scenarios
where plugin developers are not aware that their functions are called via SOAP.

Maybe there are other plugins which generate HTML output when hooking
EVENT_REPORT_BUG, ....

Another side effect I found: After the suggested change the EmailReporting
Plugin [3] will signal two times EVENT_REPORT_BUG

[1]
https://github.com/mantisbt-plugins/timecard/blob/master/Timecard/Timecard.php#L60
[2]
https://github.com/mantisbt-plugins/timecard/blob/master/Timecard/Timecard.php#L124
[3]
https://github.com/mantisbt-plugins/EmailReporting/blob/master/core/mail_api.php#L807

All of these are good points. This is why the parent issue is targeted for 1.3.