View Issue Details

IDProjectCategoryView StatusLast Update
0016964mantisbtotherpublic2017-06-26 08:13
Reporterinfo4km Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
Summary0016964: All field values should be validated when moving an issue
Description

When moving an issue from one project to the other it would be beneficial if Mantis would warn the user or even stop the user from doing so without updating fields that don't have valid values.

In 1.2.x I know it is possible to generalize the Category field if it doesn't match.

I am thinking that it should stop you completely if you need to update a field first.

Additional Information

This became important because we have a synchronization tool that uses the Mantis web services API to update values from another tracking system. We moved a bunch of issue and the "Version" related fields had values from the original project that were not valid for the new project. When the synchronization ran, the api did not accept this because it tried to update the field with the value it had.

TagsNo tags attached.

Relationships

related to 0014863 new Lack of enforcement of required fields when moving issues between projects leads to inconsistencies 

Activities

info4km

info4km

2016-02-11 11:30

reporter   ~0052513

Additionally, if an issue is moved and the target versions for example are no longer valid, they get blanked out in the target/resulting project. This is fine except the history does not show it. so we had no idea where that issue was before.

However when we decided to move it back to the original target, the fields were restored because the database records still held the original information.

I think the history should show a line for it, for example here is what was shown when we moved an issue:
02-08-16 13:53 jdoe Project ourProj1.0 => ourProj2.0
02-08-16 13:53 jdoe Assigned To jdoe => jsmith
02-08-16 13:53 jdoe Status waiting for response => assigned

I think the following and possibly other values too - should show, so we know that the original ourProj1.0 values are being ignored:
02-08-16 13:53 jdoe Target Version upd1.0 =>

Note that I guess it does not record it because the values aren't actually changed in the db. They are still there for the old project.

That is probably what complicates this. so this is just an enhancement suggestion. maybe upon the original creation the values should be listed. not really sure.

info4km

info4km

2017-06-26 08:13

reporter   ~0057138

I've just noticed also that if a custom field is not in the original project and the issue is moved, the custom field value is not updated/added in the new project. Basically there seems to be no record for the issue in the new project with that custom field. Then when you search -- you are actually missing issues.