Inconsistency in the application of multiple recipe rules on the same field

After the parser update, there is an inconsistency in the manner in which multiple recipe rules applied to the same field.

Prior to the update, multiple rules were additive.
Example 1:

JITTER StudyDate 1
JITTER StudyDate 2

Results in 3 days being added to StudyDate.

Example 2:

ADD PatientIdentityRemoved Yes
REMOVE PatientIdentityRemoved 

Results in no change to the header.

Example 3:

REMOVE StudyDate 
ADD StudyDate 20200806

Resulted in StudyDate having a value of 20200806.

After the parser update, any actions following a REMOVE rule are ignored. As a result, while Examples 1 and 2 still operate the same, Example 3 fails to add the new StudyDate to the header.

I believe that this is occurring because the REMOVE action (specifically parser.py - delete_field()) removes the specified field from the FileDataSet in the parser.dicom property but is not removing the item from the fields property. In subsequent ADD rules, we fall into the add_field function and since the deleted field is still in parser.fields the add is treated as a replacement (line 377) which updates the element, but the tag with the new value is never re-added to the parser.dicom FileDataSet.

I have a few unit tests written for the examples that I’ve outlined above - but haven’t implemented a solution yet (the new tests can be seen in this commit). I wanted to get your perspective first. My first thought was to ensure that the REMOVE action removed the element from the fields property in addition to what it currently does.

While all of the above may seem like nonsense - “Why wouldn’t you just compress each of these scenarios down to three single rules?” - the REMOVE/ADD scenario does have real-world applicability for situations like:

REMOVE endswith:ID
ADD PatientID 12345

[vsoch]

Fixed with #141

[wetzelj]

I like typical. 😃 It’s switched to deepcopy.