Invalid Attachment - Can't continue workflow

TeamSite 7.2.1
Windows 2008 R2

It seems that when you have a file that has not been submitted to STAGING attached to a job and then delete it, the tasks will display a message stating that you have an invalid attachment. No big deal except when the Group task is taken, none of the transition buttons are displayed to move the workflow along. Is there any way to disable this behavior?

We submit files to STAGING after they are deployed to a production environment. When a user wants to delete a file in QA that has never been submitted to STAGING, they start the job first by selecting it and going to New Job as usual, and then delete the file. This make sure the file is in the file list used by OpenDeploy and since the file no longer exists, it deletes the file on the target server when deployed.

This worked without issue in previous versions. Only now in 7.2.1 are we running into the invalid attachment error message.

Find more posts tagged with

Comments

Rick Poulin

It sounds to me like what you really need is an "unpublish" workflow where the file is only deleted from TeamSite after the deployment (your OD would build a filelist as normal, but reference a dummy area such as /tmp where the files don't exist, causing the deletions on the target). Yeah, that's a cop out for something that used to work and rightly still should, but FYI if you ever start using the PLC workflow, "shadow references" cause a whole lot more problems there so I'd guess that practice is only going to get worse.

Adam Stoller

TeamSite 7.2.1
Windows 2008 R2

It seems that when you have a file that has not been submitted to STAGING attached to a job and then delete it, the tasks will display a message stating that you have an invalid attachment. No big deal except when the Group task is taken, none of the transition buttons are displayed to move the workflow along. Is there any way to disable this behavior?

We submit files to STAGING after they are deployed to a production environment. When a user wants to delete a file in QA that has never been submitted to STAGING, they start the job first by selecting it and going to New Job as usual, and then delete the file. This make sure the file is in the file list used by OpenDeploy and since the file no longer exists, it deletes the file on the target server when deployed.

This worked without issue in previous versions. Only now in 7.2.1 are we running into the invalid attachment error message.

Is the file deleted before, or after, the job was instantiated?

If the file was deleted before the job was instantiated it should all work correctly (i.e. the group tasks and the [file] deployments)

If the file is being deleted after the job is instantiated, but within the context of the workflow, you may have to try removing and re-adding the deleted file from / to the task (I'm not sure how easy it will be to do that) or - you might be be able to just explicitly refresh the task object (assuming the file is being deleted within the context of something like an external or cgi task)

If the file is being deleted outside the context of the workflow, but after the job has been instantiated - you can try removing / re-adding the deleted file within the workflow, but I am not as optimistic that this would work.

Sample Donut.rptdesign

Rick Poulin

Ghoti, I think you missed the part where he says he's deleting a file that has never been submitted, so there's no CSHole to attach to a workflow. Instead, the file is just plain gone, leaving a null reference in the tasks that used to reference it. Your suggestions won't work because there's nothing to attach/reattach after the deletion.

Assuming the group task is broken as you (KevNet) state and you don't want to build an unpublish workflow, you might have to use cgi/external tasks in between group tasks to remove broken refs and store them in job vars, and update your deployment task to match. That sounds like more work than having two wfs pointing to the same model and just getting your deploy task to behave differently based on the wf name...

Adam Stoller

Ghoti, I think you missed the part where he says he's deleting a file that has never been submitted, so there's no CSHole to attach to a workflow. Instead, the file is just plain gone, leaving a null reference in the tasks that used to reference it. Your suggestions won't work because there's nothing to attach/reattach after the deletion.

Ah yes, so I did - sorry.

Assuming the group task is broken as you (KevNet) state and you don't want to build an unpublish workflow, you might have to use cgi/external tasks in between group tasks to remove broken refs and store them in job vars, and update your deployment task to match. That sounds like more work than having two wfs pointing to the same model and just getting your deploy task to behave differently based on the wf name...

Well, going back to my previous response, erroneous as it may have appeared - try this:

Yes - this means you have to "pollute" your branch with a file that's never going to actually be published (at least not right now), but it should fix the problem of trying to have a reference to a completely nonexistent, non-hole, file associated with the task(s).I'm assuming that this is a rare one-off kind of issue that manual steps are okay for - otherwise you could try to automate it (I'd probably using a custom menu item using iwsubmit rather than using the OOTB Submit Workflow).

Kevin Butcher

I think the way I'm going to handle this is to create a user task for a "Rollback" deployment. If the users selects "Rollback QA", the external task handling the deployment will deploy from the latest EDITION instead of from the WORKAREA.

Our EDITION and therefore STAGING areas in TeamSite are always kept in synch with what is in Production because we do not submit files unless they are successfully deployed to Production.

This means the file doesn't exist in the latest EDITION since it was never deployed to production and submitted. When OpenDeploy will deploys from the EDITION path the file will be deleted. After the deployment the user can delete the file in TeamSite with no issues.

This is also a good way to rollback multiple changes to QA.