What happens to postfunction changes after the issue was stored in the database?

Ovidiu Vasilescu

I have a few postfunctions that I've added that are changing some fields after the system step "Update change history for an issue and store the issue in the database."

 

I have a Clone step after the issue was updated with a few fields specified in the transition screen. What I want is to make some additional changes to the issue before it gets cloned but I don't want these changes to persist on the original issue. For now, this is working perfectly: the changes are made and it's reflected in the cloned issue as intended. The changes don't appear in the change history of the original issue nor are they saved on the original issue in any way.

 

 Is there some residue / risk involved with this method? I'm quite happy with how it's working out so far.

Ovidiu Vasilescu

In case this is not clear (it probably isn't), my postfunction list looks like this:

1. Set issue status to the linked status of the destination workflow step.
2. Add a comment to an issue if one is entered during a transition.
3. Update change history for an issue and store the issue in the database.
4. <change customfield_x>
5. Clone issue
6. Re-index
7. Fire event

 

Customfield_x is properly set for the cloned issue but is missing from the original issue (intended). What I'm asking is if there's any chance of this biting me if I use it long term. Is there any chance of customfield_x changing value on the next transition? Or are all changes after step 3 discarded completely after the event is fired?