View Issue Details

IDProjectCategoryView StatusLast Update
0020774mantisbtauditingpublic2019-08-25 13:15
Reportervboctor Assigned Tovboctor  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version1.3.0-rc.1 
Summary0020774: Creating an issue should only generate one history record
Description

In the simple case, we generate a single history record (new issue). However, in several cases we create extra records:

  1. When assigning the issue during reporting it.
  2. When setting custom fields.
  3. When setting tags.

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:

  1. Unnecessary entries in issue history.
  2. Each of these records are counted as an action in the anti-spam quota.

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.

TagsNo tags attached.

Activities

cproensa

cproensa

2016-04-02 14:01

developer   ~0052899

I'd rather have a fix that moves history responsibility into BugData class, instead of relying on history_log_event_direct().
At the moment, not recording history for status and handler id on BugData->create(), probably fixes your point (1)

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.
This cant be an inmediate fix, but imho, this kind of design should be on the roadmap.

calling a history API that disables recording of history entries for the rest of the request

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.
Also, disabling history for that span of time, could disable also the history record on other existing issues that may be modified as a side effect. For example: bug relations, or custom actions by plugins.
My concern is that this proposed fix is too broad.

vboctor

vboctor

2016-04-02 23:00

manager   ~0052900

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.

vboctor

vboctor

2016-04-30 18:05

manager   ~0053045

Here is an example for creating an issue with a handler with no custom fields:

2016-04-30 14:55 vboctor New Issue
2016-04-30 14:55 vboctor Status new => assigned
2016-04-30 14:55 vboctor Assigned To => joe

If a tag is selected, that adds another record

2016-04-30 14:55 Tag Attached: tag1

vboctor

vboctor

2019-08-25 13:13

manager   ~0062653

The entries for status and assigned to have been removed, but add tag are still being created.

Issue History

Date Modified Username Field Change
2016-04-02 13:17 vboctor New Issue
2016-04-02 14:01 cproensa Note Added: 0052899
2016-04-02 23:00 vboctor Assigned To => vboctor
2016-04-02 23:00 vboctor Status new => assigned
2016-04-02 23:00 vboctor Note Added: 0052900
2016-04-30 18:05 vboctor Note Added: 0053045
2019-08-25 13:13 vboctor Note Added: 0062653
2019-08-25 13:15 vboctor Category bugtracker => auditing