I’m working on a project that uses five different SharePoint Designer work flows to handle some document approvals. SPD provides the "collect data from a user" azzjoni sabiex inkunu nistgħu pront lill-utent għall-bits differenti ta 'informazzjoni, bħal jekk japprovah, xi kummenti u forsi jistaqsu dak li kellhom għall-pranzu oħra bil-lejl.

The forms are perfectly functional. They are tied to a task list as a content type. They are 100% system-generated. This is their strength and weakness. If we can live with the default form, then we’re good to go. Madankollu, we don’t have too much control over how SPD creates the form. If we don’t like that default behavior, għandna bżonn li tirrikorri għal tricks varji biex tikseb madwar dan (per eżempju, iffissar tal-prijoritajiet fuq kompitu).

I meħtieġa biex tipprovdi link fuq dawn il-formoli task li fetħet il-proprjetajiet view (dispform.asxp) of the "related item" in a new window. This provides one-click access to the meta data of the related item. This is what I mean:

Thankfully, we can do that and it’s not very hard. Broadly speaking, fire up SPD, navigate to the directory that houses the workflow files and open the ASPX file you want to modify. These are just classic XSL transform instructions and if you’ve mucked about with itemstyle.xsl, tfittxija jew xenarji XSL oħra, this will be easy for you. Fil-fatt, Sibt li huwa li huma ġeneralment aktar faċli peress li l-forma iġġenerat huwa kemmxejn aktar faċli biex isegwu meta mqabbel ma 'qalba riżultati web part tfittxija (jew il- CWQP nightmarish).

Of course, there is one major pitfall. SPD’s workflow editor expects full control over that file. If you modify it, SPD will happily overwrite your changes give the right set of circumstances. I did two quick tests to see how bad this could get. They both presuppose that you’ve crafted a valid SPD workflow that uses the "collect data from a user" pass.

Test 1:

• Tibdel il-fajl ASPX bl-idejn.
• Tittestja (tivverifika li l-bidliet tiegħek kienu salvati sew u ma kisritx xejn).
• Jiftħu l-fluss tax-xogħol u żid azzjoni relatati (such as "log to history").
• Salv l-fluss tax-xogħol.

Riżultat: F'dan il-każ, SPD ma jerġgħu joħolqu l-forma.

Test 2:

• Jagħmlu l-istess bħal #1 except directly modify the "collect data from a user" azzjoni.

Riżultat: Dan jerġa 'joħloq il-formola mill-bidu, over-miktub tibdil tiegħek.

Noti finali:

• Mill-inqas żewġ azzjonijiet tad-DPW joħolqu forom bħal dan: "Collect Data From a User" and "Assign To Do Item". Both of these actions’ formoli jistgħu jiġu modifikati manwalment.
• I kien kapaċi li tiġġenera link tiegħi biex dispform.aspx minħabba, f'dan il-każ, the relate item always has its ID embedded in the related item’s URL. I was able to extract it and then build an <a href> based on it to provide the one-click meta data access feature. It’s unlikely that your URL follows this rule. There may be other ways to get the ID of the related item but I have not had to cross that bridge, so I do not know jekk jiġrilha l-naħa l-oħra tal-chasm.
• I ma investigatx, iżda I ma tkunx sorpriż jekk ikun hemm xi tip ta 'fajl template fil- 12 doqqajs li I jista 'jbiddel għal jaffettwa kemm SPD jiġġenera l-forom default (ferm simili nistgħu timmodifika templates twissija).

</aħħar>

Abbona għall-blog tiegħi!