Loading...

RE: Issue with Quest custom action button

RE: Issue with Quest custom action button

#5706
Anonymous
Anonymous
Participant

Here is what I have done in the past (we have a better method now using custom code but this works). Granted there is a bit of "smoke and mirrors" as the saying goes:

Main Form M

Webpart page W (create it to look appropriate so it fits the look and feel of M): I am going to assume that you have created web part pages before that emulate the default Read/Edit/New forms that you normally have associated with a list. So you are familiar with passing a querystring parameter so that W opens the correct item, etc.

Put a button on M that opens W. W is actually a webpart page with both a Read and an Edit qListForm webpart. The Read one contains enough information to sufficiently identify the item. The Edit one contains no visible edit fields. Really all the user sees of the Edit qListForm is the button bar (turn off the Read qListForm button bar). The Edit qListForm's save button can be re-titled so that it is appropriate; the user doesn't necessarily need to know they are doing another save here.

The key here is two-fold:

1. include a hidden field on W that contains a fixed value. This fixed value is specifically for the action that you want the workflow to take.

2. Create or modify your workflow that fires on change. Add logic that looks for the special value that you set in #1. If that value is present, then your workflow branches off and does the action that you originally wanted. It also resets the value of the hidden field to null or something that won't trigger the action again in case the workflow fires again.

That is a brief overview; let me know if you need more explanation.

– Jim

Message was edited by: Jim Boling (revised to clarify paragraph 2)