Exporting to Excel
In my first example, we had users who were rolling up list data onto a reporting page. From this page they wanted to export a different view of the list that we had set up for them. That, however, required them to navigate to the list and use the export to Excel button in the Ribbon menu:
var href = “http:// [sharepoint] / [site] /_vti_bin/owssvr.dll?CS=109&Using=_layouts/query.iqy&List=[List Guid]&View=[View Guid]&CacheControl=1”
$(“.Caption a”).prop(“href”, href);
This will give you a button to export whatever view of the list you would like to Excel:
As much as, I’d like to take credit for this discovery, check this link below for the thread and this link to another blog with that solution.
Add to Outlook Calendar
In my second example. we created a SharePoint calendar for users to manage events. A workflow sends them an email with the link to the event when they change the category of an event indicating that this is an event they will be attending.
Like the first example. this is also pretty simple. We created a calculated column with the value of the link below:
http:// [sharepoint] / [site] / [list] /_vti_bin/owssvr.dll?CS=109&Cmd=Display&List=[List Guid]&CacheControl=1&ID=&Using=event.ics
Notice the event.ics at the end which give us an ics file to create an Outlook calender event. This can then be included in the workflow email and will give them a link like the below:
In a SharePoint list after clicking on the “Add new item” button, users will be taken to a form, fill out information and click save. At this point the form closes and the user can see the new item in their list. But what about when users want to add several items at once without clicking “Add new item” each time?
Luckily, there is the PreSaveAction() function that can be used to perform certain actions before the item is saved to the list:
First, CurrentURL will look something like this: http:// [SharePoint ]/ [site] / [list] /newForm.aspx.
Secondly, I am saving the source parameter (where I want to redirect to — this form to add another item), in a variable called redirect. redirect will look something like this: ?Source=http://[SharePoint]/[site]/[list]/newForm.aspx. Keep in mind that appending the ?Source parameter to a SharePoint URL will control where the user is redirect after saving an item. In my case I can redirect them back to the newForm after saving an item.
Third, on the save button click, I call my PreSaveAction() function, which prompts the user to create another item, if they say no, the item is saved and the window is closed. If they say yes, window.location.search is set to the redirect variable. window.location.search returns the querystring which is exactly the part I want to set. This will then save the item and then redirect the user to the newForm where they can submit another item.
One of the things I find myself looking up frequently is Date Values for SharePoint. When creating custom display forms, you typically end up with date and time values that look something like this: 2013-07-24T21:00:00Z. This isn’t really a useful value (to an end user). To change it to something more readable open designer and the disp form:
Find the date field:
I’ve made two posts about this in the past: one about running previous versions of workflows and another about workflows not publishing.
In the first post, I discovered that when running workflows in the 2010 platform previous versions may need to be deleted; in the second, I found that the activity cache on your local machine can prevent new versions of your workflow from being published.
This post is related. If a workflow fails to run with the error: something went wrong to try again reload the page and the start the workflow, you may need to restart two services. To do so check the server SharePoint is on and look for the two services:
- Service Bus Gateway
- Service Bus Manager Broker
If either of these services is stopped, restart them and try to rerun your workflow.
So this can be incredibly frustrating. You update a workflow, save it without errors and then publish, but the next time the workflow runs your changes aren’t there and it’s running an older version. I have a post about dealing with an issue like this, but after following my own advice and clearing out the previous versions, I still had the same problem . I stumbled upon this blog post that explains the problem. There is a SPD activity cache for your local machine and clearing that out will solve the problem.
The path for me on 64 bit Windows 7 looks like this: %System Drive%\Users\%user name%\AppData\Local\Microsoft\WebsiteCache. Inside that directory there was a folder for each SharePoint site I have worked on and occasionally an identically folder with “01” or “02” after the name. All of these directories can be deleted. Make sure you have closed SPD designer before deleting the directories, then reopen designer and publish a workflow.
I recently had a requirement to have a choice column with check boxes and have all options selected by default. After a little hunting I came across the syntax which is rather easy:
In the default value box, select Calculated Value and enter the above.
This leads to check boxes being selected on item created.
Stumbled upon this post when trying to use the ULS logger to see an error:
See the blog above for full details but here is a simplified way to get an error:
1. Get correlation id from window
2. in PowerShell (run the following commands):
Merge-SPLogFile -Path “.\error[x].log” -Correlation “85ea729c-071c-d0b1-d6c7-065c6284a50f”
I name my log errorx where x is a number and delete them after I I’m done.
Saves to C:\Users\ [your user name]
3. Open ULS Viewer > Open File and select error[x].log
Way easier than hunting through ULS logs.