Friday, July 5, 2013

World Clocks in Webpart










SPD Workflow facts


SharePoint designer worklfows are sequential workflows.
Statemachine WorkFlow is a collection of sequential workflows.
Statemachine workflows are well suited for workflows that require human interaction.
List workflows : run in the context of one list item or library document.
Site workflow : It does not run in the context of any list item or library document. With a site workflow, you are not limited to working with a single item or document anymore.
--use a site workflow when you want to work on multiple items or documents
SharePoint Designer does not support site workflows, it will suppoer only list workflows.
Actions : are the individual tasks that a workflow performs during its execution.
An action can be sending an email, assigning a task to someone, creating a new list item, or performing many other tasks.
The terms actions and activities refer to the same thing
A branch in a SharePoint Designer workflow is an action or set of actions that the workflow performs if a condition is met.
A branch can also have no conditions and is then called a default branch.
The default branch will execute if none of the conditions on other branches is met or if there are no branches with conditions at all.
If multiple conditions are met, the branch defined first in the step will execute.
Workflow Step
A workflow step is just that, a step of a workflow. Each step comprises at least one branch that again comprises one or more actions. Each step will perform only one branch and thus only one set of actions.
Initiation Parameters
Initiation parameters are values that the user starting the workflow enters before the workflow starts. The initiation parameters are stored in variables so you can access the values during the workflow execution.
Workflow Forms
The pages that the users see while interacting are called workflow forms.
SPD workflows cannot do loops, at least not by default. By loops, I mean an iterative task performed repeatedly, such as modifying all items in a list or sending an email to remind people about a task every day.
SPD workflows have a limited set of activities. It is quite possible to use these activities to achieve impressive results, but you are still limited more in what you can do than you are in other workflow scenarios, such as Visual Studio workflows. For example, you cannot create state machine workflows without getting very creative.
Although you can create new activities to use in SharePoint Designer, this requires programming skills or the addition of third-party tools.
Not only can you reuse your workflow in multiple sites and farms, but you can even export your workflow into other tools for further refinement.
SharePoint Designer workflows are not just limited to SharePoint Designer, however, because you can export your workflows from SharePoint Designer to Visio or even Visual Studio. You can even import Visio workflows back into SharePoint Designer, regardless of whether you started by exporting a SharePoint Designer workflow to Visio.
You can export SPD workflows to Visual Studio to further refine or expand your workflow, but once you do, you cannot import the workflow back into SPD.
List Workflows
A list workflow in SPD 2010 is the same type of workflow that was available in SPD 2007.
A list workflow is forever tied to a single list and cannot be reused later.
Once you’ve attached a workflow to a list, there’s no supported way to change that list affiliation. However, you can still change the workflow process.
This also applies to the same list in a different site.
You cannot export the workflow from one site to another site, effectively killing the reuse of list workflows. Another consequence of this is that you have to create all your production workflows in your production environment.
Reusable Workflows

The reusable workflow addresses the problem of list affiliation. This type of workflow, introduced in SharePoint 2010, solves list affiliation by simply not being tied to a list at all.
because the workflow has no idea on what kind of list it will run in, it also cannot use any of the columns in any of those lists.
It allows you to connect a workflow to a type of content(Content Type) rather than where that content is stored(Lists/Libraries).
Site Workflows
It won't work on lists/libraries.
There are many situations in which you don’t want to work directly with a specific piece of data. For example, if you don’t have that data yet but require someone to upload or add that data, you’d want to run a workflow outside the context of a specific item or list.
SPD 2010 comes in two flavors, a 32-bit edition and a 64-bit edition.
If you plan on using both SPD 2007 and SPD 2010 on the same machine, you need the same edition of both software packages.
SharePoint Designer 2007 is available only in 32-bit edition
Your SharePoint Designer 2010 flavor must match the Office version you have installed, if you have one. Thus, if you have a 32-bit Office edition installed, you also need the 32-bit edition of SPD 2010.
Backstage UI
One of the things you will notice is the “backstage” view that the Office 2010 suite of applications has implemented to replace the Office Button from Office 2007.
You will also notice the Ribbon, which is new for Designer 2010.
You will also see some options that are unique to SharePoint Designer 2010. Most of this is for creating new lists, pages, and workflows
On the left side is navigation listing the various items in your site: lists, libraries, site pages, assets, content types, and so on. This is also a huge improvement from SPD 2007 where you only navigated content and not types of items.

Hide Context Menu items-SP

/script src="" type="text/javascript"//script//script /src="" type="text/javascript"//script//script type="text/javascript"/

$('.ms-MenuUIPopupBody').live('mouseover', function() {


Expand and Collapse Webparts

/script type="text/javascript"/


// Expand/Collapse Buttons

// Feedback and questions:


function WPToggle(thisId, ImageId)


if (document.getElementById(thisId).style.display=="none")



document.getElementById(ImageId).src = "/_layouts/images/minus.gif";





document.getElementById(ImageId).src = "/_layouts/images/plus.gif";



function ExpandCollapseBody()


var i = 1;

var WPid = "WebPartWPQ1" ;

var WPtitleid = "WebPartTitleWPQ1" ;

var Toggleid = "ToggleImage1" ;





document.getElementById(WPtitleid).innerHTML = 'Expand/Collapse' + document.getElementById(WPtitleid).innerHTML ;

if (document.getElementById(WPid).style.display=="none")


document.getElementById(Toggleid).src = "/_layouts/images/plus.gif";



catch(err) {}

i = i + 1;

WPid = "WebPartWPQ" + i ;

WPtitleid = "WebPartTitleWPQ" + i;

Toggleid = "ToggleImage" + i;

} while (document.getElementById(WPid))




Hide Column based on Logged in user-SP

/script src="/..../jquery.min.js" type="text/javascript"/ script/script type="text/javascript"/

ExecuteOrDelayUntilScriptLoaded(checkUser, "sp.js");

// Function to check if user belongs to specific group or not and hide/unhide the control

var collection;
var user;
var group;
var userCollection;

var usercount=0;
function checkUser()


var ctx2 = new SP.ClientContext();
collection = ctx2.get_web().get_siteGroups();
group = collection.getById(5);
user = ctx2.get_web().get_currentUser();
userCollection = group.get_users();
ctx2.load(userCollection);//, 'Include(loginName)');
ctx2.executeQueryAsync(Function.createDelegate(this, this.onUserSuccess), Function.createDelegate(this, this.onUserFailed));

function onUserSuccess()
if(user.get_loginName() == userCollection.itemAt(i).get_loginName())
HideField("name of the column");
function onUserFailed()
function HideField(title){
var header_h3=document.getElementsByTagName("h3") ;
for(var i = 0; i {
var el = header_h3[i];
var foundField ;
for(var j=0; j{

if(el.childNodes[j].innerHTML == title

el.childNodes[j].nodeValue == title)


var elRow = el.parentNode.parentNode ; = "none"; //and hide the row

foundField = true ;






break ;