This article explains the steps to display list in subsites: http://blogs.msdn.com/jackiebo/archive/2007/02/27/displaying-a-list-on-another-site-in-the-same-site-collection.aspx
Article in progress...
Filter list views by user groups
Though SharePoint Designer is a powerful tool, but even then there is a limitation to filter list views by user group. Only filter that can be applied is by using keyword [Me]. So if current user is the member of any group, then the [Me] keyword filter won't work.
The alternative idea is to use the Membership comparator, which is used by the "By My Groups" view. The Membership comparator seems to work just like the other comparators ("is equal to", "is greater than", "is less than", etc), but is not available in the "Filter" section of view.
Try following these steps:
The alternative idea is to use the Membership comparator, which is used by the "By My Groups" view. The Membership comparator seems to work just like the other comparators ("is equal to", "is greater than", "is less than", etc), but is not available in the "Filter" section of view.
Try following these steps:
- Create a new view, and open the corresponding Aspx in Sharepoint Designer
- In the source code, locate the ListViewXml tag
- Inside this tag, locate the Where clause (begins with "<Where" and ends with "/Where>")
- Replace the contents of this tag with the following:
<Where><Or><Membership Type="CurrentUserGroups"><FieldRef Name="AssignedTo"/></Membership><Eq><FieldRef Name="AssignedTo"/><Value Type="Integer"><UserID Type="Integer"/></Value></Eq></Or></Where>
Save the page, and you're ready to go.Migrate SPD Workflows
Quite often I need to copy a workflow to another site or site collection (e.g. when provisioning an intranet portal for another client). I usually use the method described here. It basically boils down to a few simple steps:
1) Open the target list/library in SPD, click New --> Workflow. Note: Obviously, all columns used in the source list or library must be present in the target one, also internal column names must match.
2) In the new workflow create 1 step that includes 1 condition and 1 action (e.g. If [field] equals 1, “Set field in current item” to 2). This step creates the .xoml and .xoml.rules files needed to migrate our source workflow.
3) Open the original source workflow in SPD, open the .xoml file as XML (Right-click --> Open as .XML) and copy its contents.
4) Open the target workflow in SPD, open the target .xoml file as XML, replace the content with the content copied in step 3.
5) Do the same for the .xoml.rules file.
Problem:
Normally after saving the files and opening the target workflow you will notice your workflow lookups display GUIDs rather than, as you would expect. fields, columns and parameters (see screenshot below). This is down to the fact that your .xoml and .rules files reference columns and lists used in the source workflow – if your target workflow is in a different site or site collection these will, obviously, not be recognized and, therefore, are displayed as GUIDs.
Old Solution:
Luckily, SPD is smart enough to re-map the workflow to the lists and columns in the current site. All you need to do is click on the GUID and press the “Add Lookup button” – you will see that SPD automatically finds the right list and field:
Pressing OK will update the field.
Now, this is all fine for a simple workflow – you just click and fix a few lookups and off you go. What if your workflow is a longer more elaborate one – containing many steps and even more lookups, especially ones looking up values in other lists? Suddenly, the above approach becomes quite a cumbersome one.
New Solution:
What I’ve been doing when dealing with longer workflows:
1) Follow the steps outline in the beginning of the post so you end up with .xoml and .xoml.rules files copied from your source workflow.
2) Make note of all the lists used in your source workflow, note their GUIDs. Do the same for the lists used in the target workflow.
TIP: You can use Sharepoint Manager 2007 to easily get the lists GUIDs
3) Open your new workflow in SPD, open the .xoml and .xoml.rules files as XML and replace the source GUIDs with the target ones.
That’s it – if you open your workflow now you’ll see all lookups display correctly and you no longer need to click through them all to have them updated.
Gotcha:
I’ve been happily using the above approach for the last year or so. However, today I ran into an issue that didn’t really make much sense. I noticed that something funny happened if my workflow used the “Create List Item” action” (I guess the same will be true for “Update List Item” and “Copy List Item” actions).
You can see in the above screenshots that all lookups are displayed correctly. However, when I click on the “Tasks” lookup (first screen) to open the Create New List Item dialog box the List value was not populated (even though it’s shown properly in the first screen). Selecting the Tasks list from the drop-down menu had the effect of creating a new action – all the previously defined fields (Description, New Employee, Assigned to) disappeared and had to be put back in manually:
This was a major issue as I had over 20 steps using the “Create New List Item” action. I obviously didn’t like the idea of re-creating each of them manually. I opened the .xoml and .xoml.rules files and looked through the code, re-created the workflow in different sites a few times and tested all I could think of. I still couldn’t figure out what the problem is. Finally I spotted the culprit.
Solution:
Turns out the lists GUIDs I pasted into the workflow’s .xoml files were in lower case. SPD was happy with that for all lookup fields. However, lower case seems to trip up the Create New List item action (and possibly other related actions – e.g. Copy List Item). The moment I changed my GUIDs to upper case (e.g. from fabe5a1-c8d0-4c72-8a66-46c6917abdb5 to 1FABE5A1-C8D0-4C72-8A66-46C6917ABDB5) things magically started to work fine – all field lookups and references mapped properly, no actions need updating. Bingo, I can now copy even large elaborate workflows in a few minutes!
Reference: SharePoint Applied
1) Open the target list/library in SPD, click New --> Workflow. Note: Obviously, all columns used in the source list or library must be present in the target one, also internal column names must match.
2) In the new workflow create 1 step that includes 1 condition and 1 action (e.g. If [field] equals 1, “Set field in current item” to 2). This step creates the .xoml and .xoml.rules files needed to migrate our source workflow.
3) Open the original source workflow in SPD, open the .xoml file as XML (Right-click --> Open as .XML) and copy its contents.
4) Open the target workflow in SPD, open the target .xoml file as XML, replace the content with the content copied in step 3.
5) Do the same for the .xoml.rules file.
Problem:
Normally after saving the files and opening the target workflow you will notice your workflow lookups display GUIDs rather than, as you would expect. fields, columns and parameters (see screenshot below). This is down to the fact that your .xoml and .rules files reference columns and lists used in the source workflow – if your target workflow is in a different site or site collection these will, obviously, not be recognized and, therefore, are displayed as GUIDs.
Old Solution:
Luckily, SPD is smart enough to re-map the workflow to the lists and columns in the current site. All you need to do is click on the GUID and press the “Add Lookup button” – you will see that SPD automatically finds the right list and field:
Pressing OK will update the field.
Now, this is all fine for a simple workflow – you just click and fix a few lookups and off you go. What if your workflow is a longer more elaborate one – containing many steps and even more lookups, especially ones looking up values in other lists? Suddenly, the above approach becomes quite a cumbersome one.
New Solution:
What I’ve been doing when dealing with longer workflows:
1) Follow the steps outline in the beginning of the post so you end up with .xoml and .xoml.rules files copied from your source workflow.
2) Make note of all the lists used in your source workflow, note their GUIDs. Do the same for the lists used in the target workflow.
TIP: You can use Sharepoint Manager 2007 to easily get the lists GUIDs
3) Open your new workflow in SPD, open the .xoml and .xoml.rules files as XML and replace the source GUIDs with the target ones.
That’s it – if you open your workflow now you’ll see all lookups display correctly and you no longer need to click through them all to have them updated.
Gotcha:
I’ve been happily using the above approach for the last year or so. However, today I ran into an issue that didn’t really make much sense. I noticed that something funny happened if my workflow used the “Create List Item” action” (I guess the same will be true for “Update List Item” and “Copy List Item” actions).
You can see in the above screenshots that all lookups are displayed correctly. However, when I click on the “Tasks” lookup (first screen) to open the Create New List Item dialog box the List value was not populated (even though it’s shown properly in the first screen). Selecting the Tasks list from the drop-down menu had the effect of creating a new action – all the previously defined fields (Description, New Employee, Assigned to) disappeared and had to be put back in manually:
This was a major issue as I had over 20 steps using the “Create New List Item” action. I obviously didn’t like the idea of re-creating each of them manually. I opened the .xoml and .xoml.rules files and looked through the code, re-created the workflow in different sites a few times and tested all I could think of. I still couldn’t figure out what the problem is. Finally I spotted the culprit.
Solution:
Turns out the lists GUIDs I pasted into the workflow’s .xoml files were in lower case. SPD was happy with that for all lookup fields. However, lower case seems to trip up the Create New List item action (and possibly other related actions – e.g. Copy List Item). The moment I changed my GUIDs to upper case (e.g. from fabe5a1-c8d0-4c72-8a66-46c6917abdb5 to 1FABE5A1-C8D0-4C72-8A66-46C6917ABDB5) things magically started to work fine – all field lookups and references mapped properly, no actions need updating. Bingo, I can now copy even large elaborate workflows in a few minutes!
Reference: SharePoint Applied
Subscribe to:
Posts (Atom)