View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0020774||mantisbt||auditing||public||2016-04-02 13:17||2019-08-25 13:15|
|Summary||0020774: Creating an issue should only generate one history record|
In the simple case, we generate a single history record (new issue). However, in several cases we create extra records:
The only reason this happens is due to an implementation detail of us calling create(), followed by the appropriate method to take these actions.
This has two side effects:
The proposed fix here is to always show 1 record when creating an issue. This can be achieved by calling a history API that disables recording of history entries for the rest of the request or until called again. Call this method after create(), causing other entries to be avoided.
|Tags||No tags attached.|
I'd rather have a fix that moves history responsibility into BugData class, instead of relying on history_log_event_direct().
Custom fields and tags, relies on having an already created bug in database. Ideally, those two types of fields should be included in some structure that allows bug actions to be performed atomically. The same functionality that BugData provides, but including: bug, custom fields, tags, notes, etc.
If this kind of control is to be done, i'd say: make it work like the email notification bypass. This is, an option that applies to the bug action, and not globally to history api.
I agree with the long term fix. For by-passing the history, we can do it per action, that should be fine. I haven't really looked at the code, I just wanted to make sure we are on the same page relating to the functional change.
Once I get to this, I will evaluate the different options.
Here is an example for creating an issue with a handler with no custom fields:
2016-04-30 14:55 vboctor New Issue
If a tag is selected, that adds another record
2016-04-30 14:55 Tag Attached: tag1
The entries for status and assigned to have been removed, but add tag are still being created.