View Issue Details

WikiRelated ChangesetsJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0025962mantisbtbugtrackerpublic2019-08-04 19:092019-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

Relationship GraphDependency Graph
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

@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 17:17

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