Archive for SharePoint 2007

JS Date functions not working in SharePoint with IE…?

Ever run into a problem where you have what you know to be valid javascript, trying to work with a Date object, and yet you keep getting JS errors in the console? If you’re working in SharePoint 2010 or older, blame Microsoft ;-)

Joking aside, even if you’re using the latest version of Internet Explorer, because of the meta tags present in the OOTB masterpages of the older versions of SharePoint, IE will load the page in an older Document Mode; IE8 Standards for SP2010 and Quirks for SP2007. You can always, of course, apply a different masterpage or customize the native ones, however you run the risk of encountering issues elsewhere – for example, remove the “IE8″ meta tag from an SP2010 masterpage (or just setting it to a newer version) causes myriad issues with controls like the People Picker, the RTF field, certain menu options in the Item Context Menu, etc.

If your organization’s timeline for upgrading to SP2013 is a long-term effort, consider allowing/enabling your users to run Firefox or Chrome (Chrome Frame was a nice alternative until it was retired at the end of 2013). I know, not the most ideal answer – but at least you can stop banging your head on your desk wondering why your perfectly valid JS for manipulating Dates keeps throwing errors in IE.

SharePoint’s Edit in Datasheet broken? Try this!

Having to support multiple clients across a myriad of SharePoint flavors, I’ve had my share of issues with Datasheet mode. On any given week, I can find myself working across SharePoint 2013 (on-prem and in Office 365), SharePoint 2010 (Foundation & Server), SharePoint 2007 (WSS & MOSS) and even occasionally still, some SharePoint 2003. Couple that with installed versions of SharePoint Designer 2013, 2010 & 2007 plus a constant flow of Windows & Office updates (I’m currently running Win8 x64 + Office 2013 x64) and I seem to regularly encounter this:

DatasheetView-Error

As has been blogged numerous times elsewhere on the web, you can often fix this error by downloading & installing the “2007 Office System Driver: Data Connectivity Components” (sometimes referred to as the “Access Database Engine”) from Microsoft here: http://www.microsoft.com/en-us/download/details.aspx?id=23734

However, all too often, I find that while installing the above allows me to then access Datasheet view, the result is a crippled version. Just some of the limitations I run into include:

  • The inability to drag & select more than one cell at a time
  • The inability to delete more than one row at a time
  • The inability to drag & move columns
  • The inability to resize columns
  • And perhaps the most limiting feature, the inability to drag the + icon in the bottom-right of a cell to auto-populate additional cells or rows

Fortunately, I found all the above (and probably more) problems are resolved with a second, less-discussed package. Also available for free from Microsoft, you’ll want to download & install the “Microsoft Office Access Runtime and Data Connectivity 2007 Service Pack 2″ from here: http://www.microsoft.com/en-us/download/details.aspx?id=7020

My guess is some, if not all, of the necessary files & configuration changes included in these packages were originally part of the Office 2007 Suite installation; so when you upgraded your installation of Office (or your entire machine) to Office 2010 or 2013, and especially if you jumped to a 64-bit version of Office, said files were no longer being found by the browser when attempting to Edit in Datasheet. In my experience across an array of machines with varying Windows & Office versions, these two packages have always restored Datasheet mode – hope they help you!

SharePoint Conference 2014 aftermath – Customizing Forms

As a blog primarily focused on the technical aspects of building applications in SharePoint, I won’t drone on about the far-reaching impacts of “The End of the InfoPath Era” – this was already announced in the weeks leading up this year’s SharePoint Conference, and then (sort of, but more on that later) given more clarity during the Conference itself. In short, although end-of-life support for InfoPath will extend until 2023, last year’s release will remain the final one to include any new features or functionality, while fixes & patches will be at the pace you’d expect from a Microsoft product on its way to sunset.

Sitting in the room at SPC14 with hundreds of my fellow SharePoint developers, users & executives, I got a first-hand glimpse of what Microsoft sees as its path, or really paths, forward. We knew Microsoft meant business when the session was given a primo time slot & 3 Microsoft employees to present; in the end, what we got was a scatter shot of four possible options for replacing custom InfoPath forms:

  1. Using Excel Surveys, an apparently little known feature for creating custom forms directly inside an Excel document & that write to a worksheet therein.
  2. Using a new, yet to be released “Forms Over SharePoint Lists” web-based designer for creating custom forms in SharePoint 2013 (and yes, that acronym is FOSL, pronounced ‘fossil’ by the MS reps themselves – insert irony joke here).
  3. Possibly using Word for structured document forms – this I say “possibly” because MS committed only to providing a roadmap for this option by the end of 2014; no actual product yet.
  4. Using Access Apps, which if you used them in SP2010, seem reminiscent of the Office Business Apps (OBAs) that were touted then.

With such a wide range of choices, and comparatively little guidance on when to use which & where, I couldn’t help but think the flexibility & power of the CorasWorks Actions Framework provides a much-needed alternative. In the coming months, I suspect more vendors will try to fill the “custom forms” gap with new products – but we’ve been building apps with & improving our Actions Framework, including our web-based designer (the Actions Wizard) for more than 8 years now; this is a feature set CorasWorks knows well!

And as an architect that’s designed & implemented 100+ custom applications on SharePoint, I also know just creating a custom form a solution does not make; what if you want to apply a custom form to more than one list, across multiple sites, site collections or web apps, with a single centralized definition – none of the MS approaches facilitate this, while the CorasWorks platform has for years. Or how about custom forms that are exposed depending on the current values or stage an item is in, can trigger Workflows anywhere in the SharePoint farm, or are security trimmed based on the currently logged in user? All core features of the CorasWorks Actions.

Plus, in the coming months, while others are just starting to explore the world of InfoPath alternatives, CorasWorks will be expanding our Action framework further to include integration with other data sources & providing greater flexibility & customizability in the form UI.

So while the InfoPath announcement and SPC14 have put the topic of custom forms for SharePoint at the forefront, CorasWorks has been building & improving our platform – which includes this key feature – since the SharePoint 2003 days.

Securing & Hardening SharePoint Sites – Part 3

Previously, we discussed how the CorasWorks platform enables working with data anywhere in your SharePoint farm, followed by some masterpage changes you can make to secure away SharePoint’s system pages within a site. In our third and final part of this series, I’ll describe how CorasWorks can be used to essentially create a secure “proxy” for use within your SharePoint-based applications.

Typically in SharePoint, if you want a user to be able to see some data, or even enable them to perform inserts/updates/deletes, you have to give that user at least direct access to the item(s), if not the parent List or even Site the data is in. However, with the CorasWorks External Data Provider – don’t let the word “external” fool you – you can actually create secured connections between a user interface on one SharePoint site and the data on another, without the logged in user actually having any access to said data.

Sounds crazy, or worse, unsecure? Not at all! The architecture supported is not unlike integrating with a line-of-business database application; a SharePoint admin can create and enable the equivalent of a service account that will be given the necessary rights to the underlying data to support the application requirements. That account’s information is then stored in secure web.config app keys. On the CorasWorks side, you can then reference the corresponding app keys in your configuration of an External Data Provider to make HTTP Post calls to any URL said account has access to – these can be calls to native SharePoint service endpoints or, even better, our own API.

From there, you can now focus on creating the optimal UI for your users and let CorasWorks handle the proxied connections between the UI and the data. The users accessing the application will only need Read rights to the UI elements, and so even if they ever figure out where the data is coming from (which they won’t, because you’ll have secured that away too), they still won’t be able to access it outside the UI you create.

If this sounds like a design pattern you need, email steve@corasworks.net and we’ll setup an architectural review to help get you started!

Securing & Hardening SharePoint Sites – Part 2

Previously we blogged about the reasons for – and potential concerns with – opening up a SharePoint application to external users. The improved collaboration and access to real-time data is certainly compelling, but what if we’re concerned savvy users might decide to poke around the SharePoint site we give them access to? Even with the proxy design available to architects using the CorasWorks platform, there’s always those users who may try to access content or underlying back-end SharePoint pages, like the “All Site Content” or “All People” pages.

Luckily, there’s a straightforward way to make some quick adjustments to a masterpage and restrict access to even those system pages for a given site. To start, let’s look at the first few lines of HTML that normally make up the body of a masterpage; this example comes from an unmodified “v4.master” in SharePoint 2010:

<body scroll=”no” onload=”if (typeof(_spBodyOnLoadWrapper) != ‘undefined’) _spBodyOnLoadWrapper();”><form runat=”server” onsubmit=”if (typeof(_spFormOnSubmitWrapper) != ‘undefined’) {return _spFormOnSubmitWrapper();} else {return true;}”><asp:ScriptManager id=”ScriptManager” runat=”server” EnablePageMethods=”false” EnablePartialRendering=”true” EnableScriptGlobalization=”false” EnableScriptLocalization=”true” />… (The rest of the page)</form>

</body>

When customizing a masterpage, one of the things you can do is add Security Trimmed Controls, which essentially allow you to wrap a block of content within your masterpage and thus restrict the display/running of it to only those users whose permissions match the settings specified. Here’s an example of one such use:

<Sharepoint:SPSecurityTrimmedControl runat=”server” ID=”HidePage” Permissions=”ManageWeb” PermissionMode=”All” PermissionContext=”CurrentSite”>

Now imagine you wanted to secure the entirety of your underlying SharePoint system pages, like “All Site Content” or your native List Views. No problem – simply wrap the entire contents of the <form> tag that encompasses the page and you’ve got a locked site where only users with sufficient permissions can access your back-end pages:

<body scroll=”no” onload=”if (typeof(_spBodyOnLoadWrapper) != ‘undefined’) _spBodyOnLoadWrapper();”><form runat=”server” onsubmit=”if (typeof(_spFormOnSubmitWrapper) != ‘undefined’) {return _spFormOnSubmitWrapper();} else {return true;}”><Sharepoint:SPSecurityTrimmedControl runat=”server” ID=”HidePage” Permissions=”ManageWeb” PermissionMode=”All” PermissionContext=”CurrentSite”><div id=”FullPage”><asp:ScriptManager id=”ScriptManager” runat=”server” EnablePageMethods=”false” EnablePartialRendering=”true” EnableScriptGlobalization=”false” EnableScriptLocalization=”true” />

… (The rest of the page)

</div>

</Sharepoint:SPSecurityTrimmedControl>

</form>

</body>

Want to display a note to users who try to sneak their way in; another simple tweak – just add a little HTML with some appropriate verbiage, then hide said message if the user does have sufficient rights:

<body scroll=”no” onload=”if (typeof(_spBodyOnLoadWrapper) != ‘undefined’) _spBodyOnLoadWrapper();”><form runat=”server” onsubmit=”if (typeof(_spFormOnSubmitWrapper) != ‘undefined’) {return _spFormOnSubmitWrapper();} else {return true;}”><div id=”ReadersMessage” style=”width:100%;text-align:center”><h1>Nothing to see here…</h1></div><Sharepoint:SPSecurityTrimmedControl runat=”server” ID=”HidePage” Permissions=”ManageWeb” PermissionMode=”All” PermissionContext=”CurrentSite”><script type=”text/javascript”>document.getElementById(“ReadersMessage”).style.display = ‘none’;</script>

<div id=”FullPage”>

<asp:ScriptManager id=”ScriptManager” runat=”server” EnablePageMethods=”false” EnablePartialRendering=”true” EnableScriptGlobalization=”false” EnableScriptLocalization=”true” />

… (The rest of the page)

</div>

</Sharepoint:SPSecurityTrimmedControl>

</form>

</body>

To learn more about the SPSecurityTrimmedControl, check out the documentation from MSDN here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webcontrols.spsecuritytrimmedcontrol_properties.aspx

The three properties you will want to focus on are the “Permissions”, “PermissionMode” and “PermissionContext” one as seen in the examples above; for reference, the examples here would hide the contents of any page using this masterpage to all users except those with Owner (or equivalent) rights on the current site.

Three Approaches to Building SharePoint Solutions

When it comes to building solutions with SharePoint, there are three approaches.

LowCode

No Code

SharePoint comes with a rich set of features and functionality that can help deliver your solution requirements.  For a feature matrix, you can refer to this SharePoint 2013 Feature Matrix blog posting.

But what if the business requirements can’t be delivered purely with out of the box capability?

Custom Code

With SharePoint Solutions, there is a general impression that the more complex the requirements are the more likely you are going to need custom code.  Depending on your organization, you may need to tap internal developers who will crack open Visual Studio and start plugging away on your requirements.  If you don’t have the luxury of having SharePoint developers you will need to employ outside consultants.

One thing to note around custom SharePoint code.  A .NET developer does not necessarily equal a SharePoint developer.  Knowing the SharePoint object model is required in addition to understanding .NET.  When doing custom code, if you treat SharePoint like all other web site development, you are likely to encounter pain later when upgrading or modifying it later.

With the specialized skills required for custom coded solutions, it requires a huge investment in developer resources, training and ongoing maintenance.  It’s quite possible that it makes it cost prohibitive to pursue solutions where complex requirements are in view.  But is there another option?

Low Code
The CorasWorks Approach

Traditional web developers are much more accessible than those with specialized SharePoint development skills.  They are also more affordable.  Most organizations have web developers with more common skills like HTML and XML along with JavaScript and jQuery.  You could train these resources to understand the SharePoint Client Side Object Model for instance but there are other options.

The “No Code” option implies being locked into certain functionality and capability.  The “Custom Code” comes with specialized resourcing requirements.  The “Low Code” option offers flexibility to meet solution requirements while leveraging more readily available resources.

CorasWorks provides a low code option through our Platform and Application Service (known as CAPS).  Our Platform and CAPS make it possible to build complex solutions with the flexibility you would expect from a custom solution but with a much smaller code footprint.  For a look at CAPS capability, please read this recent blog article outlining those capabilities.

With CorasWorks, your traditional web developer can build a feature rich, complex solution with less code and using the skills they already possess.  Our off the shelf solutions have taken this approach and it’s available for you to build your own solutions.  Have you taken some projects off the SharePoint solution roadmap because their requirements would have forced you down a custom development approach?  Well grab some pizzas, one of your traditional web developers, a copy of CAPS and reinstate those projects.  You’ll be surprised at what you can build with this low code approach.

Prevent Edit in MS Word (or any App) in SharePoint

Recently we were faced with the requirement from a client that wanted to be able to edit a Microsoft Word document accessible via SharePoint (via a link) but ensure that once the document was closed, the user could no longer edit it. Thanks to the way Microsoft Office maintains the linking of documents between the client and SharePoint when opening a file, it is easy for a user to view the link to a document or List Item attachment when it opens and then, when saving, see the original file location on the server.

Our issue became how do we lock down the file without a lot of manual permissions but still allow a user to click a link and download a copy of a document. What we crafted was a solution that leveraged the native “_layouts/download.aspx” page to effectively break the link between the file in SharePoint and the local copy a user opens on their machine. Within our documents display, we simply dynamically generate hyperlinks using the following format:
<<YourSiteURL>>/_layouts/download.aspx?SourceURL=<<YourFileURL>>

Doing so ensures the copy of the file downloaded to the client machine has no URL or link back to the original location, and thus obscures the ability for a user to click & open a document in SharePoint and then easily save it back to SharePoint – because in this case, that’s exactly what we did not want. As an added perk, since the display was built via XSLT (remember, CAPS supports XSLT 2.0), we were also able to conditionally build the link to the documents based on the overall item status.

Blanking Out a Date Field via SharePoint Designer Workflow

I recently came across a requirement on a customer project to set a Date field within a SharePoint List item to empty/blank/null – however you think of it – during a SharePoint Designer Workflow if a certain condition was met. I already had my workflow in place and running, so I figured the client request would only take a few minutes:  add a “Set Field in Current Item” action to my workflow, choose my Date field, plug in an empty value (or a space if need be), and be done.

And then I had one of those “Ugh, SharePoint!?” moments…

As it turns out, you cannot use the “Set Field in Current Item” action to blank out a date field. No problem I thought, I’ll just trick SharePoint.  I’ll create a workflow variable, use the string builder to make it empty, then set my Date field to the variable. But no, bested again. L

I turned to Bing and ran through a couple more attempts – one suggestion was to create a second Date field the user never sees, leave it blank for all time, and “copy” that value into the Date field I wanted blank, but this seemed like overkill.  In the end, I paired two suggestions from similar use cases to get the following solution, which has been deployed and working within the customer’s Production environment for more than a month without a single hiccup:

  1. Create a Workflow Variable named “Empty Date”
  2. Use the Dynamic String Builder to set “Empty Date” to 1/01/0001
  3. Use the Set Field in Current Item action to set your Date field to the Workflow Variable “Empty Date”
  4. Rejoice!

I’ll defer to the SharePoint Product Team as to why the date January 1, 0001, somehow equates to no date, or even why it doesn’t work if you just try to set the Date field to that value directly, but this combination of a Workflow Variable and that value did the trick. Chalk it up to just another one of those SharePoint things!

 

Custom “Sign in as a Different User” button in SharePoint

Whether you’re working in SharePoint 2007, 2010 or 2013, you may have a need to create a custom “Sign in as a Different User” button within your site design. On a recent project for a client, we were creating a Customer Portal that was external facing and were using a custom masterpage that included removal of the native SharePoint ‘Welcome’ menu, where the “Sign in as a Different User” is normally found – or in the case of SharePoint 2013, not found at all.

There’s a simple way to wire up your own custom element that will trigger the same behavior as the “Sign in as a Different User” menu option. In SharePoint 2007, just wire up the following function call to any element within your layout/page:

LoginAsAnother(‘/_layouts/accessdenied.aspx?loginasanotheruser=true’,0);

Meanwhile, in SharePoint 2010 or 2013, the function call is simply to a slightly different application page:

LoginAsAnother(‘/_layouts/closeConnection.aspx?loginasanotheruser=true’,0);

That’s it! Now you can create any button, image, hyperlink or other markup you want that, when clicked, will pop the “Sign in as a Different User” prompt, then redirect back to the current page.

Toolbar (or Browser Add-In) trick for SharePoint and CorasWorks

Regardless of which version of SharePoint you’re using, there’s any number of menu options, Galleries, settings pages, etc that you need to access on a daily basis. Depending on where you are in a Site and what you want to do, the menu option you need might be two or three clicks away – with a page load/refresh between each.

There was a time when CorasWorks provided an Internet Explorer add-in called the “CorasWorks Toolbar” that made access to all these pages quick & easy, along with a great number of useful CorasWorks options. However, as browsers are ever changing and the memory required to run each add-in affects the overall browser experience, we’ve deprecated the Toolbar in favor of a much simpler & more customizable approach – bookmarks!

CorasWorksMenus

As you can see from the various options listed, access to all the common pages within SharePoint are exposed through the menu options listed. The “menus” are really just folders of Bookmarks that, once imported into your browser, appear within the browser’s Bookmark Toolbar. Some of the most click-intensive options like trying to Import a Web Part (clicking Edit Page, then Add a web part, then Import button, all with a refresh between each) are now single-click options.

To get all these options, simply download this ZIP file CorasWorks Bookmarks, unzip it and either Import the bookmarks within your browser or, for Internet Explorer on Windows, copy them to the Favorites Folder within your User folder. In a fast-paced work environment, like the rapid AppDev cycle us CorasWorks Consultants are used to, every saved click and page refresh is the best gift of all – the gift of time!