View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0020577||mantisbt||plug-ins||public||2016-02-07 18:45||2017-12-04 02:25|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||2.10.0||Fixed in Version|
|Summary||0020577: Consistent use of EVENT_UPDATE_BUG_DATA|
Currently the event EVENT_UPDATE_BUG_DATA (chain) is only triggered from the bug_update page.
|Tags||No tags attached.|
Proposal sounds OK to me, but how do you propose to restrict use of bug_set_field(), more to the point, how to enforce such a restriction ?
I mean "restriction" as reviewing current use and change into BugData higher level operations whenever its appropiate. Enforcing is not possible, nor recommended...
So one point of discussion here is to delimit which changes should be treated "silently", and which one should trigger side events and notifications
See related issue in Source integration plugin https://github.com/mantisbt-plugins/source-integration/issues/189
I copy and answer here @vboctor comments on the PR966
I understand your proposal as having a dedicated class for each event
This expands the idea of a dedicated class, which would be populated with some/all of the Bugdata properties, in this example.
In a future where more object-mapping is used to manage all application entities, this may make sens, to have
If we are worried about potential changes in BugData class, then the right move is to clean up that class. This class
This may be out of scope. Currently plugins currently have access to all core functions, without restrictions.
If i understand correctly, that's how it's supposed to work. Maybe it has not been made clear enough in the documentation.
Ideally, and i have it planned for a later change, is to move some validation/changes into this workflow inside BugData.
All the stuff about managing callbacks inside the BugData class is to adapt the current core actions to this requeriment,
Currently, the non-obviusly-documented method to stop a update execution is to throw an error. This is an all-or-nothing approach
Your suggestion would mean that a true or false must be explicitly returned by each plugin, and the event manager then stops the
The update methods provide parameters for both the modified BugData object, and the previous unchanged object. This was existing
In a totally personal note: i really need this functionality as soos as posible. This has been in work since 1.3.0.
Answering some of the inlined comments:
Yes, i did. However, at the moment i've tried to keep it simple.
It's done somehow with other callbacks. For example:
|2016-02-07 18:45||cproensa||New Issue|
|2016-02-08 04:28||dregad||Note Added: 0052480|
|2016-02-08 04:49||cproensa||Note Added: 0052483|
|2016-02-14 11:07||cproensa||Note Added: 0052517|
|2016-06-12 02:37||atrol||Target Version||1.3.0-rc.2 => 1.3.0|
|2016-07-10 07:57||atroladmin||Target Version||1.3.0 => 1.3.1|
|2016-07-11 16:18||atrol||Target Version||1.3.1 =>|
|2016-07-27 19:14||vboctoradmin||Relationship added||related to 0021557|
|2016-07-27 19:14||vboctoradmin||Assigned To||=> cproensa|
|2016-07-27 19:14||vboctoradmin||Status||new => assigned|
|2016-07-31 19:29||cproensa||Note Edited: 0052517||View Revisions|
|2016-12-30 11:25||dregad||Note Added: 0054878|
|2016-12-30 11:26||dregad||Target Version||=> 1.3.5|
|2016-12-30 16:24||atrol||Target Version||1.3.5 => 1.3.6|
|2017-01-01 11:44||cproensa||Note Added: 0054884|
|2017-02-01 22:47||vboctor||Target Version||1.3.6 => 1.3.7|
|2017-02-26 21:19||vboctor||Target Version||1.3.7 => 2.3.0|
|2017-04-01 00:20||vboctor||Target Version||2.3.0 => 2.4.0|
|2017-04-30 14:53||vboctoradmin||Target Version||2.4.0 => 2.5.0|
|2017-06-04 16:19||atrol||Target Version||2.5.0 => 2.6.0|
|2017-09-03 18:50||vboctor||Target Version||2.6.0 => 2.7.0|
|2017-10-08 23:55||vboctor||Target Version||2.7.0 => 2.8.0|
|2017-10-28 19:14||vboctor||Target Version||2.8.0 => 2.9.0|
|2017-12-04 02:25||vboctor||Target Version||2.9.0 => 2.10.0|