View Issue Details

IDProjectCategoryView StatusLast Update
0025962mantisbtbugtrackerpublic2019-08-25 12:36
Reporterdregad Assigned Tovboctor  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version2.13.0 
Target Version2.22.0Fixed in Version2.22.0 
Summary0025962: IssueAddCommand does not create history entries identical to the code it replaced
Description

IssueAddCommand was introduced in 2.13.0 via 0023998.

Executing PHPUnit tests as follows:
phpunit --bootstrap tests/bootstrap.php tests/soap/IssueHistoryTest.php --filter testCreatedIssueWithNonDefaultStatusAndResolutionHasHistoryEntries

The test case is documented to create a new issue with non-default status and resolution and validate that history entries are created for the status and resolution.

  • succeeds in 2.12.2 and earlier; history items are created as
    2019-08-05 01:00    administrator       New Issue   
    2019-08-05 01:00    administrator       Status  new => confirmed
    2019-08-05 01:00    administrator       Resolution  open => reopened 
  • fails in 2.13.0 and later; only a single history record is created
    2019-08-05 01:02    administrator       New Issue   

Offending commit according to git bisect is MantisBT master b03448f2

TagsNo tags attached.

Relationships

related to 0023998 closedvboctor Implement IssueAddCommand and use it from SOAP, REST and Web UI 
related to 0025961 closeddregad PHPUnit tests as run by Travis CI builds do not execute all defined suites 
related to 0014678 closedrombert Allow resolving a bug when it is reported 

Activities

vboctor

vboctor

2019-08-04 21:19

manager   ~0062507

PR: https://github.com/mantisbt/mantisbt/pull/1538

dregad

dregad

2019-08-05 04:29

developer   ~0062509

Last edited: 2019-08-05 04:30

View 2 revisions

@vboctor you stated in chat

This isn’t new behavior and I probably did it intentionally. Having change history events upon creation of an issue seems wrong and likely side effects of old implementation.

Looking at the history of the change (see 0014678, and more specifically MantisBT master 921a4005 ), it appears to be fully intentional (i.e. not a "side effect") that status and resolution were logged separately after issue creation. I can understand the reasoning behind @rombert's original implementation, which better documents that the issue was opened and immediately resolved.

I'm not saying that's correct, but at least that explains why it was done that way.

dregad

dregad

2019-08-20 03:56

developer   ~0062613

After discussion we agreed that the new behavior will be kept, so the unit tests will be adjusted accordingly.

PR 1538 has been closed, and the change included in https://github.com/mantisbt/mantisbt/pull/1540

Related Changesets

MantisBT: master b13c301e

2019-08-04 21:17:52

vboctor


Committer: dregad Details Diff
Fix test case to expect one history entry

When creating an issue with non-default status/resolution, check that a single entry is created.

Fixes 0025962
Affected Issues
0025962
mod - tests/soap/IssueHistoryTest.php Diff File

Issue History

Date Modified Username Field Change
2019-08-04 19:09 dregad New Issue
2019-08-04 19:09 dregad Status new => assigned
2019-08-04 19:09 dregad Assigned To => vboctor
2019-08-04 19:09 dregad Relationship added related to 0023998
2019-08-04 19:10 dregad Relationship added related to 0025961
2019-08-04 21:19 vboctor Note Added: 0062507
2019-08-05 04:29 dregad Note Added: 0062509
2019-08-05 04:30 dregad Relationship added related to 0014678
2019-08-05 04:30 dregad Note Edited: 0062509 View Revisions
2019-08-20 03:56 dregad Note Added: 0062613
2019-08-24 22:19 dregad Changeset attached => MantisBT master b13c301e
2019-08-24 22:19 vboctor Status assigned => resolved
2019-08-24 22:19 vboctor Resolution open => fixed
2019-08-24 22:19 vboctor Fixed in Version => 2.22.0
2019-08-25 12:36 vboctor Status resolved => closed