Display a List Web Part View Using a Query String Parameter

So what if you want to have a single “dashboard” page that displays a number of web parts, including a list web part? You’d like to provide multiple links to the page which will display slightly different views of the information. In this case, you may want to think about using the view query string parameter in your links to change the view of the list web part displayed.

To get a list view GUID/s add the list web part to your page and filter the list. You can then look at the URL to find the GUID, e.g. https://server/sites/subsite/Shared%20Documents/Dashboard.aspx?View={CEF00598-91B2-456E-8068-F351BC9CC1BA}

Change the web part View property to access different view GUIDs. Once you have a GUID for each view, you can add the ? or & View={GUID} to your dashboard hyperlinks.

Click the hyperlinks and bingo-bango, you should see your list web part displays the relevant view. This should not effect any other web parts also on the page, as the view GUID is unique to the specific list.

 

Display List in Sub Site

So, I’ve been doing a bit of work on a 2007 environment lately so this solution is specifically for 2007 BUT I will provide a link to the 2010 script as well, so don’t worry.

Here is a bit of script that will let you display a list view on a sub site page. Paste it into a Content Editor web part but be sure to update the URL of the list view you want to display. Also, if you find you get an error, you can add ?contents=1 to your page URL and delete the CE web part if you need to.

The script comes from the following post: http://blog.pathtosharepoint.com/2009/01/22/a-simple-method-to-display-a-list-in-another-site/

and here is a jQuery adaptation that works well too: http://www.balestra.be/2012/04/want-to-display-a-sharepoint-list-from-another-site-collection-use-these-2-lines-of-jquery-script.html

<DIV id="ListPlaceholder"><IMG src="/_layouts/images/GEARS_AN.GIF"></DIV>
<!-- Paste the URL of the source list below: -->
<script type="text/javascript">
function DisplayThisList()
{
var placeholder = document.getElementById("ListPlaceholder");
var displaylist = null;
var sourcelist = document.getElementById("SourceList");
try {
   if(sourcelist.contentDocument)
      // Firefox, Opera
      {displaylist = sourcelist.contentDocument.getElementById("WebPartWPQ2") ;}
   else if(sourcelist.contentWindow)
      // Internet Explorer
      {displaylist = sourcelist.contentWindow.document.getElementById("WebPartWPQ2") ;}
   else if(sourcelist.document)
      // Others?
      {displaylist = sourcelist.document.getElementById("WebPartWPQ2") ;}
}
catch(err) { alert ("Loading failed");}
displaylist.removeChild(displaylist.getElementsByTagName("table")[0]);
var allDescendants = displaylist.getElementsByTagName("*");
for (i=0;i<allDescendants.length;i++) {
allDescendants[i].removeAttribute("id");
allDescendants[i].removeAttribute("onclick");
allDescendants[i].removeAttribute("onfocus");
allDescendants[i].removeAttribute("onmouseover");
}
placeholder.innerHTML = displaylist.innerHTML;
}
</script>

 

Display All Appending Field Entries in a Single List View

Saving a list  template with content and then creating a list using that template doesn’t bring across append field history. This is to be expected really but it’s a pain if you are trying to migrate the content to a new site collection. I found a cool way to get around this though; which requires manually copying the append history into the destination list’s datasheet view. To be able to do this, you first need a way of displaying all the appended comments together (viewing append fields in the item display form or library views only show the latest entry). Below I will describe how to do this. I’m sure there are other good reasons to display all append entries in one view but here I will outline the steps to migrate the content:

1.     Add your newly created list (from template with content) to a blank web part page (as a list web part). Make sure the current view is displaying the append field and any others you are interested in.

2.     Export the list web part file by following the instructions in this post (who wrote this? It is friggin awesome!)

3.     Edit the file and you will see the XSLLink property points to the main.xsl file. Download this file and rename to main_showappend.xsl

4.     Edit main_showappend.xsl and take note of the import of fldtypes.xsl. Download this file and rename to fldtypes_showappend.xsl

5.     Upload both fldtypes_showappend.xsl and main_showappend.xsl to a library in your SharePoint site and then Edit main_showappend.xsl to update the import ref to point to your   fldtypes_showappend.xsl

6.     Now edit fldtypes_showappend.xsl and find the FieldRef_Note_body template. Update as below:

<xsl:template name=”FieldRef_Note_body” ddwrt:dvt_mode=”body” match=”FieldRef” mode=”Note_body”>

<xsl:param name=”thisNode” select=”.”/>

<div dir=”{@Direction}”>

<SharePoint:AppendOnlyHistory FieldName=”MyAppendField” runat=”server” ControlMode=”Display” ItemId=”{$thisNode/@ID}”/>

</div>

</xsl:template>

7.     So now you have 3 filesmain_showappend.xsl is in SharePoint and imports fldtypes_showappend.xsl from your SharePoint library. Your list web part file is open on your desktop. Update this file to point the XSLLink value to  the URL of main_showappend.xsl in SharePoint. Save the file.

8.     Now return to your web part page in SharePoint. Delete the current list web part and import your custom web part file. Voila! Now you should see your list displaying the append field entries all together.

AppendFields

9.     Now you can “page scrape” this page to copy the append field values- organize in an excel spreadsheet if you need to, and then paste into the new list datasheet view. I actually turned off append while I did this and then turned it back on afterwards. This gives all your historic entries in one entry and then allows you to continue to append single comments going forward.

Hope this was helpful.

e

Exporting a List Web Part – Made Easy

So as you already know, list web parts are not exportable via the UI menus. That option is inconveniently missing. There are a few ways however, to get around this but the option I will describe here does NOT require SharePoint designer. Now, now, quiet down with the cheering and the celebration and follow these simple steps:

  1. Navigate to the list you want to export as a web part and Edit the page
  2. Open your browser’s Dev Tools and search the HTML for MSOMenu_Export
  3. If you examine the attributes of this menu item, you should see the onmenuclick Javascript. Copy the Javascript call
  4. In your list page, open the list web part menu (as if you were going to delete/minimise/export it). This is very important.
  5. Paste the Javascript into the browser URL bar and hit enter
  6. Now you are prompted to Save or Open the .webpart file and voila!

Page Not Found When Accessing Library Link

You know when you are training someone up in SharePoint (for a support role) and you are thinking- ‘this one is going to be trouble’. Well, that happened to me and my project team recently. With one person in particular there was a language barrier, a geographic barrier and to be honest, an attitude barrier as well. She didn’t fail to disappoint anyway. On day one she managed to create a number of new document libraries in a live site, purely for her own amusement and practice, and then she broke one bad enough that my team couldn’t find it to delete it. When I clicked the link to the library on the Quick Launch menu I received a “Page not found”. So I  navigated to the View all site content menu and clicked the library. This came up with a blank SharePoint page. I deduced that the blank page was where the library used to be; our SharePoint support star had just deleted the library web part on that page. All I did was edit the page, add the library web part back and then access the library settings to finally delete the pesky “Training for Me” library.

Removing Recently Modified Pages section on Quick Launch

It is a pain when you create a new wiki page and you just want it to look like the default page, but it doesn’t because its got this Recently Modified section on the top of the Quick Launch. Here is how you get rid of that eyesaw:

Add a CEWP to the page and switch to the HTML/source view of the web part

Paste in this style override:

<style>

.s4-recentchanges {

DISPLAY:none; }

</style>

Save the page and navigate away, then back to see the section gone.

List and Library Permissions Visibility

With SharePoint allowing security to be managed all the way down to the item/document level, it can easily become quite a mystery to users- just who has access to what exactly? The best way to avoid this confusion is to avoid item level security and only break permission inheritance at the libray level when really necessary. Below is a neat little way (I think) to show users who has access to the library they are currently working within, just in case they want to think twice about sharing.

Create a new document library view called Library Permissions. Open the new view and edit the view page. Minimise the document library web part and above it either add a CEWP to describe the level of access and add links to the relevant groups OR a Site User web part configured to show the Contributors group on the library. This view is a quick and easy way  for users to access this security information but be aware that the library tabs will not function on this view page (unless the user clicks the minimised library web part). The view breacrumbs can be used to navigate back to the library. There is a small maintenance overhead as well. If extra groups are added to the library permissions then this view would need to be updated to reflect this. The best thing about linking to the Contributor group though is that the members will likely change but not the group itself.

Alternatively you can add a description and link in the list/library descritpion field (settings). This isn’t quite as pretty as links in the description field can not be entered as HTML so the link is displayed in full.

I have implemented some sites with “security folders” because of the need for fine-grained permissions. In thoses cases I have created a custom folder content type : Secure Folder and added a mandatory people/groups field. This can then at least be displayed against the folder in all views. Again, there is a maintenece overhead here but it worth it if you are breaking permissions at that level.