SharePoint 2013 JavaScript Copy List Item

I have a SharePoint 2013 custom list based form with 160 fields where there is a need to template list items and copy those items as new items.  I could have used SSOM since my solution is for an on-premise implementation but I prefer to use JSOM especially since my client wants the ability to move this solution to the O365 in the future.  MS documentation was helpful on using JSOM to manipulate list items but of course it didn't get into copying items.  I couldn't find any posts specific for the copy list item topic from others other than some related clues on stackoverflow.  The SSOM technique for copying list items was the starting point for this solution and was helpful but it wasn't as easy as finding an alternative JSOM object to the SSOM object.  So through a days worth of hit and miss and a lot of debugging, here is my JSOM code to copy a SharePoint 2013 list item.  I created a custom JSLink view of this list where I override the "Title" field with a "New from Template" button.

//Called from JSLink field override on the Title field, add new request button which will copy this template list item
function GetTemplateLink(ctx) {
    var ret;
    //get id of this item
    var srfID = ctx.CurrentItem.ID;
    ret = TemplateLink(srfID);
    return ret;
}
function TemplateLink(item_id) {
    //when user clicks button, copy of this item will be created and open in a new window in Edit mode
    return "<input type='button' value='New Request' onclick='jsNewFromTemplate(" + item_id.toString() + ",true);' title='New Request Form' class='clsFormButton' style='width:80px;'/> ";
}

var tempctx, tempItem, fieldCollection, tempList;

//load the list, the field collection for this list, and the item
function jsNewFromTemplate(id, isTemplate) {
    tempctx = SP.ClientContext.get_current();
    this.web = tempctx.get_web();
    tempctx.load(this.web);
    tempList = web.get_lists().getByTitle('Study Request');
    tempctx.load(tempList);
    fieldCollection = tempList.get_fields();
    tempctx.load(fieldCollection);
    tempItem = tempList.getItemById(id);
    tempctx.load(tempItem);
    tempctx.executeQueryAsync(Function.createDelegate(this, this.createListItem), Function.createDelegate(this, this.createListItemFail));
}
//create a new item and load it
function createListItem(sender, args) {
    var itemCreateInfo = new SP.ListItemCreationInformation();
    this.oListItem = tempList.addItem(itemCreateInfo);
    oListItem.update();
    tempctx.load(oListItem);
    tempctx.executeQueryAsync(Function.createDelegate(this, this.copyListItem), Function.createDelegate(this, this.createListItemFail))
}
//copy field values from original item into the new item
function copyListItem(sender, args) {
    this.newListItem = tempList.getItemById(oListItem.get_id());
    //customize title with unique ID
    newListItem.set_item('Title', '8' + oListItem.get_id());
    newListItem.update();
    //enumerate the list fields and update values
    var fieldEnumerator = fieldCollection.getEnumerator();
    while (fieldEnumerator.moveNext()) {
        var oField = fieldEnumerator.get_current();
        //exclude fields
        if ((!oField.get_readOnlyField())
            && (oField.get_internalName() != "Attachments")
            && (!oField.get_hidden())
            && (oField.get_internalName() != "Title")
            && (oField.get_internalName() != "ContentType"))
        {
            //get value of source field
            var sourceVal = tempItem.get_item(oField.get_internalName());
            if (sourceVal != null)
            {
                //set value on new item
                newListItem.set_item(oField.get_internalName(), sourceVal);
            }
        }
    }
    newListItem.update();
    tempctx.load(newListItem);
    tempctx.executeQueryAsync(Function.createDelegate(this, this.showForm), Function.createDelegate(this, this.createListItemFail))
}
//open copied item in editform.aspx
function showForm(sender, args) {
    var newsrfID = newListItem.get_id();
    var win = window.open(CreateFormUrl(tempctx, newsrfID), '', 'left=10,top=10,width=1000,height=800,toolbar=1,resizable=1,scrollbars=1,status=1');
    win.focus();
}
function createListItemFail(sender, args) {
    alert('Request failed. ' + args.get_message() +
        '\n' + args.get_stackTrace());
}
//function to get edit form
function CreateFormUrl(ctx, linkID) {
    var titleUrl = [];
    titleUrl.push(ctx.editFormUrl);
    titleUrl.push("&ID=");
    titleUrl.push(linkID);
    titleUrl.push("&isdlg=1");
    return titleUrl.join('');
}

SharePoint 2013 On-Premise or Office 365 and SharePoint Online?

I’ve worked with clients who struggle with the decision whether to implement SharePoint 2013 on-premise or move to the cloud-based Office 365 and SharePoint Online solution.

Administrative Tools and Controls

In the past, I was sure I’d always recommend on-premise mainly for the administrative control it provides but lately, when working with clients I’ve come around to recommending Office 365 and SharePoint Online mainly for the same reason I love on-premise…administrative control.  Administrative control is great if you have staff who understand and can support the potential complexity of a SharePoint 2013 on-premise implementation. But why deal with that administrative complexity and configuration when you can pay Microsoft to worry about that? From small businesses to large enterprises, I’ve heard worry in the voices of IT engineers and support staff when we dig into the design for SharePoint 2013 on-premise.

SharePoint Deployment for Small Organizations – Typical Approach

First let’s start with smaller organizations with less than 1000 users.   Typically, these organizations start with a grassroots IT implementation of SharePoint with a one or two server tiered deployment.  This is manageable initially but along the line management wants to increase adoption of SharePoint as a tool that can handle collaboration on documents very well, provide rich search, and integrate with other systems already running at the company.  With this desire for increased use, the IT staff know they need high availability, redundancy, and recoverability which you don’t get with a simple two server deployment.   This is when the IT staff, who is able to support the simple implementation, knows they need help and call on consultants.

SharePoint Deployment for Small Organizations – Enhanced Database Management

The consultants come in and define the business requirements and start getting into a design for Load Balanced Web Front Ends, Clustered or Mirrored SQL Servers, an application server tier with redundancy for Search, and a logical design with multiple web applications and site collections with defined quotas for better managing content databases – and the IT staff sit there with the deer-in-the-headlights look wondering how they’re going to be able to support this increased complexity. Then the consultants pile on designs for recovery, scaling the environment (considering how they want to scale workflow, distributed cache, office web apps server, BI elements including SQL Server Reporting Services and SQL Server Analysis Services, and Branch cache servers for better WAN performance…because management has these requirements), and patching all these new servers with daily maintenance which in some cases is going to need more tools (i.e., more cash) and definitely more staff to support (i.e., more cash).

Better Administration and Performance – Office 365 and SharePoint Online

At this point the IT Staff are ready to jump off the roof.   Oh, and management wants external access for employees and partners so the consultants get into the design for external access with talk of DMZ, SSL, remote proxy servers, SharePoint Antivirus, and federated authentication.  By this time, the IT staff are in such terror of the administration nightmare ahead that have jumped off the roof...actually, they’re saying to the consultants, “So tell us more about this Office 365 and SharePoint Online.”

SharePoint 2013 vs. SharePoint 2007 or 2010 – Understanding Deployment Complexities

Second, there is every organization with more than 1,000 users and ditto to everything for small organizations but in this case, the IT staff is already supporting a complex SharePoint 2007 or 2010 deployment (or both) with terabytes of content… which they now have to migrate and / or upgrade… but it turns out that SharePoint 2013 has tripled the complexity and scale where in the previous versions they were just supporting everything contained in SharePoint now they’re introduced to supporting a separate infrastructure for Workflow (i.e., Workflow Manager 1.0), Distributed Cache, Enterprise Search (Formerly Fast Search for SharePoint), and Office Web App Servers – it was hard enough patching SharePoint servers and now they’ve got to patch and scale more servers.  And remember the migration/upgrade... which could take months... migration / upgrade equals supporting 2 (or 3) versions of SharePoint until everyone’s off the old version(s).

Migration and Customization – on-premise, hybrid on-premise or cloud implementation

Oh, and then there are all the customizations that the larger organizations have done. Now the IT staff has to figure out how that’s going to work.  To be fair, they’ve got to figure out how to do the migration and customizations with Office 365 and SharePoint Online too where the complexity is most likely harder and may be the reason that larger organizations stick with an on-premise implementation and maybe consider a hybrid on-premise/cloud implementation.  Some of these large organizations have also let their implementations get out of hand so now they need to really bear down on a strong governance plan for the new SharePoint 2013 implementation with a desire for better SLAs where before maybe high availability at the server level was enough with a scheduled weekend outage once or twice a year for patching, now they need strategies where there is no downtime because some sites need to be up all the time so they need synchronized active/active server farms so they can have sites running live on a backup server farm while the production farm is being patched…of course some companies have been doing this with prior versions of SharePoint but the point is, with SharePoint online, you pay Microsoft to deal with this complexity instead having facilities, hardware, processes, and staff of your own to deal with this.

Office 365 and SharePoint Deployment

You will also find in most cases that business usage requirements, information architectures, and logical designs fit in either an Office 365 and SharePoint Online deployment or an on-premise deployment. If you’re a company which has customized SharePoint with a lot of server side code, when you bring up SharePoint online to developers and application support, you’ll probably get push back where they have to get up-to-speed and may have to rebuild solutions with the new client side development and app models.

Share Pointe Online for better SLAs

Going back to my original thought, I love administrative control and most IT managers, engineers, and architects do but in the end SharePoint is a business solution and not an IT solution.  So decisions around SharePoint have to put the business first.  SharePoint online is a good business solution with SLAs often better then what an on-premise solution offers so the IT managers need to change their mindset when it comes to SharePoint online.   You still need people to administer SharePoint online but in most cases you can do it with less staff.  Also, think of the simplistic 80/20 rule where 80 percent of the use in SharePoint is for out of the box functionality and 20 percent is for custom solutions (which may be closer to 90/10 based on the organizations where I’ve worked).  SharePoint online is a perfect solution for the 80% use without the maintenance complexity.

Bottom-line – Cost Factor

I won’t get into the cost comparison in this post because it’s different for each organization where some organizations have existing data center infrastructure which can support the new on-premise implementation while others need to buy more hardware and software outside of the SharePoint servers but when I’ve done assessments in the past and looked at the costs and savings of on-premise versus online, it can be close.