Since MOSS 2007, SharePoint workflow statuses display with a text value such as “Canceled”, “Completed” or “In Progress”, but behind the scenes are stored as a key with an integer value. So in a view when you want to filter based on the workflow status you must use this key value, and not the display text.
As an example, here’s what the Filtering section would look like if I were filtering out items where the workflow status were either “Completed” or “Canceled”:
Here are the values and definitions for each workflow status, which still apply in SharePoint 2010:
- 0 – Not Started
- 1 – Failed On Start
- 2 – In Progress
- 3 – Error Occurred
- 4 – Canceled
- 5 – Completed
- 6 – Failed On Start (retrying)
- 7 – Error Occurred (retrying)
- 15 – Canceled (defined but not used)
- 16 – Approved
- 17 – Rejected
Hope this serves as a quick reference, it will for me!
I ran across a discussioni online today (can’t recall where it was, unfortunately) that mentioned what to do when you put a SharePoint web part (2007 or higher) on a site and it breaks, or the web part itself is faulty. You’ll usually get an error page that you can’t get past. The solution is rather easy…append “?Contents=1” to the end of the site url. For example, if your site that you put the web part on is “http://server/path/site/subsite/SitePages/Home.aspx”, your new URL will look like this:
You’ll be taken to the Web Part Page Management page for that site, where you can remove the selected web part and restore the page’s functionality.
You may or may not have seen the following error message when trying to remove an InfoPath Form Template in Central Administration-Application Management-InfoPath Forms Services / Manage Form Templates:
“The timer job for the operation has been created. However, it cannot be run because the administrative service for this server is not enabled…”
In my case, this is due to Network restrictions. Although I’m a site collection admin and a Farm Admin, AND a local admin on the server (and it’s a dev server on top of that), I’m not a Domain Admin and neither is the service account for SharePoint, which causes a whole host of other problems. For those in that situation (and so I don’t forget how I did it so I can fix it again later) this is the solution to that issue.
The timer job may show up as “Failed”, but the event is still lingering in the database. It can be kicked off using the STSADM command as follows:
From the command line on the affected server, navigate to C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12bin and use the following command:
stsadm.exe -o execadmsvcjobs
This will launch all outstanding events the timer job tried to kick off but couldn’t, in the order they were received. In my case, I even discovered a few things that tried to launch on their own but couldn’t, like Anti-Virus updates and patches. Interesting. Hope this helps someone someday. It’ll at least help me again when I forget how I got it to work that one time. ; )