0017907: add the ability to indicate in the issue history that modification had been made by a plugin - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0017907	mantisbt	plug-ins	public	2014-11-20 15:01	2014-12-08 02:18

Reporter	Mr.Bricodage	Assigned To	dregad
Priority	normal	Severity	feature	Reproducibility	always
Status	closed	Resolution	no change required
Product Version	1.2.17

Summary	0017907: add the ability to indicate in the issue history that modification had been made by a plugin
Description	If we use a plugin that modify issue field(s) content(s), we cannot see in issue history information that the plugin made modification(s). The provided modification allow a plugin to log some information in issue history
Additional Information	example of use (see uploaded file to see result): log in history the begin and the end of data importation through import plugin (to view easily in history which elements have been modified by import) : `# log begin before import plugin Treatment history_log_event_special( $bug_id, DATA_IMPORTED, plugin_lang_get('plugin_name'), plugin_lang_get('text_begin_importation') ); # Import treatment for $bug_id [...] #End of Import Treatment for $bug_id # log end after import plugin Treatment history_log_event_special( $bug_id, DATA_IMPORTED, plugin_lang_get('plugin_name'), plugin_lang_get('text_end_importation') );`
Tags	patch
Attached Files	result.DATA_IMPORTED.jpg (15,480 bytes) result.DATA_IMPORTED.jpg (15,480 bytes)

Mr.Bricodage 2014-11-20 15:03 reporter ~0041871	https://github.com/mantisbt/mantisbt/pull/547

dregad 2014-11-21 08:14 developer ~0041875 Last edited: 2014-11-21 08:14	I understand your requirement, but after a quick look at your pull request I'm not convinced that it is necessary. Why don't you use plugin_history_log() ?

vboctor 2014-11-22 15:05 manager ~0041878	Yep, that seems like the approach we support right now for plugins. There are a couple of scenarios: A plugin modifying standard fields. In such case, the normal history log entries will be generated with no attribution to the plugin code. A plugin modifying its own fields or providing semantics markers for a task like import. In this case, it will reference plugname_fieldname as the field name. I think the current approach is probably good enough.

Mr.Bricodage 2014-11-27 15:33 reporter ~0041932	Ok, you're right, I'll use the provided function as mentionned. Bug and merge request can be closed. Sorry for the inconvenience. Regards.

dregad 2014-11-27 17:39 developer ~0041933	No problem. It's great that you submitted a patch, even if in the end it was not accepted. I hope this will not discourage you from future contributions. Thanks for the feedback.