Archive for the ‘SP2010 UI’ Category

Steve Peschka put together a great blog post about Bypassing the Multi Authentication Provider Selection Page in SharePoint 2010 that was also incorporated in a Microsoft MSDN article. (If you’re not concerned with SharePoint 2010 and are here for info regarding SharePoint 2013, skip down to the “SharePoint 2013” heading.) The workaround Peschka provides works, but I had a few issues with how it was put together:

  1. It’s not a solution deployment. Manual. 😐
  2. You’re replacing an out-of-the-box page. What happens to your changes if a CU updates that page? :-/
  3. The change affects all web applications ran on the WFE server you make the change on. What if you have a web application you don’t want to auto-select a provider?

My first issue was disappointing. My second issue was risky. My third issue? Just not acceptable because we do have multiple web applications and don’t want all of them to auto-select. (more…)


Read Full Post »

Radu Tut did a wonderful blog about how to get Search Analytics Reports programmatically in SharePoint 2013. I am quite grateful for his guidance and it’s undoubtedly the most referenced article on the topic (even being referenced in Microsoft blogs and other documentation).

I followed Radu’s guidance and have successfully retrieved usage data from my site collections in 2013, but I’ve discovered a few things I’ve not seen anyone talking about:

  1. It is important to note that the DateTime value you use should be UTC. If not, you will, at some time during the day–depending on your offset–get a “Specified argument was out of the range of valid values” error when trying to get the furthest back data (example: -14 days for Day) if you use Local time. Internally, SharePoint uses DateTime.UtcNow.Date (see reflection of Microsoft.Office.Server.Search.Analytics.AnalyticsItemData in the Microsoft.Office.Server.Search.Applications.dll).
  2. To my surprise, I was able to retrieve usage data from a 2010 site collection in SP2013! Apparently, SharePoint is tracking and compiling this data, but the 2010 UI has no way to interface with the data. Thus, if you need usage data for a 2010 UI site collection in SharePoint 2013, turn to your Devs or PowerShell-savvy Admins: If your site is being crawled, the 2013 usage data you seek is in there!
  3. The time period for SP2013 to compile usage data is fairly lengthy (at least 15 minutes in my tiny dev farm). If you attempt to retrieve the data while SharePoint is compiling it, you’ll get back a big fat ‘0’. For expected results, make sure you’re not retrieving the data while SharePoint is compiling it. 🙂 I believe this compilation is done by a timer job once a day at midnight, by default (I was up pretty late working on my project when I discovered this behavior).

Happy reporting!

Read Full Post »

Warning: Fluffy explanation content ahead! If you want to skip the background info and get straight to the meat of this post, skip the next few paragraphs.

I would like to start this post by giving credit where credit is due. A few years ago, Mark Wilson wrote a blog post on how to use calculated fields to control the coloring of calendar items in the calendar view with some custom JavaScript (see SharePoint 2010 Colour Calendar post SP1 update). Without thinking too terribly much about how it was put together or worked, I put it into play with a solution that used event receivers to update a Single Line Text field to the values needed for Mark’s script (a Calculated field was too simple to meet the full business requirements). Worked beautifully!

Upon testing the solution in SharePoint 2013, I found it didn’t work. And, not just a little: Badly! No calendar events would show on the calendar and the ribbon would get stuck in “Loading…” So, I returned to Mark’s blog and was happy to find his update, SharePoint 2013 Colour Calendar. Reading through the comments, I was surprised to see a stream of people mentioning Mark’s script wasn’t working shortly followed by Mark’s “I fixed it” reply. Something was wrong here that needed a deeper look.

Turns out, Mark has been copying the code from Microsoft’s scripts and appending a line to execute his ColourCalendar function. That works just fine until Microsoft modifies their scripts–which is precisely what has been happening frequently in SharePoint Online (o365). Even his 2010 version of the scripts had to handle the pre- and post-SP1 releases differently. (No fault of Mark. The changes were just too drastic.) I, for one, wasn’t interested in getting into a “test and modify” loop every time I needed to deploy a Cumulative Update. Not only that, but the scripts Mark provides are UI specific. I wanted–and pretty much needed (see my last post)–one script that could handle the different UIs by itself and not be subject to continual necessary updates because of changes made by Microsoft.

There were two key elements to meeting my requirements to handle the UI versions and cumulative updates without troubles:

  1. _spPageContextInfo.webUIVersion: This allows us to test which UIVersion is being used by the page. Important when you consider that the DOM changes quite considerably with each UI version.
  2. Extending JavaScript functions without overwriting them: This allows us to insert our own function call without needing to copy the original function’s code. (My thanks to “xdazz” for the answer to this one on Stack Overflow.)

Integrating all of this together with the Module Pattern best practice gained from Scot Hillier’s SPC2012 session, “A Primer in HTML5 and JavaScript,” I came up with a new script that can be used in UI version 4 or 15 in SharePoint 2013.

Script source: DynamicCalendarColor.docx

To use the script source, download it and save the contents as text-only as ‘DynamicCalendarColor.js’ (you can use a different name, but be sure to modify the last line accordingly). From there, follow Mark’s rather well written instructions on SharePoint 2013 Colour Calendar. Be sure your page also loads the jQuery libraries! (I don’t include that in my script because jQuery is often used in many other solutions, as well. Don’t want to be loading it twice.)

There you go: You’re now a SharePoint Calendar Artiste!

Read Full Post »

Any of the following sound familiar?

  • I’m getting an error when viewing my calendar. The error says, “The Web application at [your URL] could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.”
  • My calendar view gives the error, “Unable to find specified web in the given URL – [URL].”
  • When I try to edit my calendar overlay, I get a “File Not Found.” error message.

You’ve probably become a victim of the Calendar Overlay’s propensity to use fully qualified URLs. You’ll likely notice when you see the first error I gave above that the domain name given in the URL does not match the domain name you are browsing the page from. Unfortunately, Calendar Overlay won’t take a relative URL. (From a development standpoint, this only makes sense when you consider that the developer short-cutted his/her code writing. Bad. Just bad. There’s plenty of people talking about this–people who have surely been listened to by Microsoft–but that’s not the point of this blog. So, moving on.)

If you’ve extended your SharePoint web application or changed your Default zone’s domain name at any time, you’ve likely become a victim of the Calendar Overlay fully qualified URLs.

Aside from the errors given above, how can I tell? Using SharePoint Management Shell, take a look at the CalendarSettings property of your views:

$w = Get-SPWeb [your site URL]
$l = $w.Lists["[your list name"]"]
$l.Views | ? { $_.CalendarSettings -ne $null } | % { $_.CalendarSettings }

CalendarSettings is a string object that contains a serialized object (i.e. the string is XML). Within that XML string is a WebUrl property like WebUrl="http://sppaule/Lists/Calendar/calendar.aspx". If the protocol and domain (ex: “http://sppaule”) don’t match the protocol and domain you browse from, you’ve got a problem (which is why you’re here reading this). From what I’ve read, both the protocol and domain must match.

“Okay, so they got me? Now what?” It’s really quite easy to fix. If you understood the PowerShell code above, you’ve probably got a really good idea of how to do it. Following is a script you can save to a .ps1 file and execute to update all the views across your entire web application. Just be patient when running it: there could be a lot of views to iterate through!

[bool]$do = $pscmdlet.ShouldProcess($currentWebApplicationURL);
if((Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null){
  $ver = $host | select version
  if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = "ReuseThread"}
  Add-PsSnapin Microsoft.SharePoint.PowerShell
  Set-location $home
  write-host "Updating CalendarSettings..."
  $gc = Start-SPAssignment
  $views = $gc | get-spwebapplication $currentWebApplicationURL | get-spsite -limit all | get-spweb -limit all | % { $_.Lists | % { $_.Views | ? { $_.CalendarSettings -ne $null -and $_.CalendarSettings -like '*'+$oldWebApplicationURL+'*' } }}
  $views | % { $_.CalendarSettings = $_.CalendarSettings.Replace($oldWebApplicationURL, $currentWebApplicationURL); $_.Update() }
  write-host $views.Count "views updated.";
  Stop-SPAssignment -SemiGlobal $gc
} else {
  write-host "Operation cancelled."

(Notice I include the loading of the SharePoint snapin just in case the file gets executed from a regular PowerShell session or the Windows PowerShell ISE–which I like to use for writing and debugging scripts.)

I saved mine on my desktop as “Update-CalendarSettings.ps1”. Then, simply execute the script like the following:

PS C:\Users\sppaule\Desktop> Update-CalendarSettings.ps1 [currentWebAppUrl] [oldWebAppUrl]

Replace [currentWebAppUrl] with your web app’s Default zone URL (ex: “http://sppaule”) and [oldWebAppUrl] with the protocol and domain that is incorrect in the CalendarSettings (ex: “http://paule”).

Note: This will replace all occurences of [oldWebAppUrl] with [currentWebAppUrl] within your whole CalendarSettings. I couldn’t think of any case where this would be bad for us, but you may know of some for yourself. If so, be sure to modify the Replace(...) as necessary.

A few other tidbits of learning to consider:

  1. If you are using a Microsoft Forefront Unified Access Gateway, you may be saying, “Well, my browser protocol and/or domain don’t match what is in CalendarSettings. Why don’t I have a problem?” I wondered the exact same. It’s because Forefront UAG translates the protocol and domain for you. Your browser may show “https://extranet.sppaule.me”, but the request from UAG to the SharePoint farm is most likely something like “http://sppaule”. When SharePoint responds back, the UAG translates any “http://sppaule” URLs to “https://extranet.sppaule.me”.
  2. It wasn’t until researching this that I realized that ListViewWebPart views are actually stored on the SPList. They’re stored as Hidden views. Makes updating the CalendarSettings WebUrl paths across the board a lot easier.

Read Full Post »

It’s been far too long since I last blogged. To my followers: my apologies. There have been some great discoveries (particularly in the last few months), but none I have had time to write about, yet. Today, I ran into an intriguing situation that I felt needed to be shared that wouldn’t take long.

Take a look at this screen shot:

Announcements list with two seemingly identical items. Only, one of the items has the "New!" icon.

Announcements list with two seemingly identical items. Only, one of the items has the “New” icon.

Notice anything funny? (Okay, so I gave it away if you looked at the caption.) We’ve got two seemingly identical announcements in this list: both have the same title, creation date, and modification date. Only, one of them is showing the New icon and the other isn’t. I had to take a hard look at this!

Let’s disregard how I got to this for now and focus on the question at hand: Why would one item show the New icon and the other item not? They both show the same Created date and that is clearly not anywhere close the the timeframe for a new item (nearly a whole year earlier). Diving under the hood with PowerShell brought about the answer.

Let’s say $i1 and $i2 are, respectively, the SPListItem objects in PowerShell from the list shown above. My first clue came from inspecting the XML of $i2. There were clearly two dates given for the creation date, as such:

ows_Created='2012-02-29 15:17:19'
ows_Created_x0020_Date='1;#2013-02-20 17:46:57'

Again, let’s disregard how I came about with two different Created dates. It becomes clear that the New icon is going off the Created_x0020_Date field data. Furthering the inspection in PowerShell, we see the following:

PS C:> $f = $i1.Fields.GetFieldByInternalName("Created_x0020_Date")
PS C:> $i1[$f.id]
2013-02-19 16:44:52
PS C:> $i1["Created"]
Wednesday, February 29, 2012 3:17:19 PM

PS C:> $f = $i2.Fields.GetFieldByInternalName("Created_x0020_Date")
PS C:> $i2[$f.id]
2013-02-20 17:46:57
PS C:> $i2["Created"]

Wednesday, February 29, 2012 3:17:19 PM

Viola! Item 1 has a Created_x0020_Date that is outside of the range for a New icon, but Item 2 has a date within the range and thus shows the New icon.

The creation date shown in list views is the Created field where Title = "Created" and InternalName = "Created". While also having Title = "Created", the field used by the New icon is the one with InternalName = "Created_x0020_Date". You never see this later field (Created_x0020_Date) in the UI because it is hidden and readonly.

I’ll discuss how I came about this duplication in my next post, Duplicated list items.

If you need to see or change the duration your web application is set to for the New icon (i.e. how long the New icon will show), use the following PowerShell (copied from Deliveron Blog):

Get The Current Duration To Display The “New” Icon
$webApp = Get-SPWebApplication "http://webAppURL/"

Change The Duration To Display The “New” Icon
# Set to 1 Day
$webApp = Get-SPWebApplication "http://webAppURL/"
$webApp.DaysToShowNewIndicator = 1

Prevent The “New” Icon From Displaying
# Essentially, just set the display duration to 0 days.
$webApp = Get-SPWebApplication "http://webAppURL/"
$webApp.DaysToShowNewIndicator = 0

Read Full Post »

Sometimes a seemingly innocent problem can lead a newbie to proclaim, “SharePoint is crap!” Of course, we know from experience this is typically due to a personal problem, not a problem with the platform. One such simply innocent problem came from a mysterious visitation by the ancient Shuar people (who’s practices included head shrinking, known as tsantsa).

From time to time, we’ve had users notice that the tabs in the ribbon get cut off or trimmed as shown below:

Shrunken/truncated/trimmed tabs

Took a while, but I finally found what is happening. It has to do with the zoom setting on your browser. The image above comes from IE8 set to 115% zoom:

115% zoom

Set the zoom level back to 100% (sometimes other zoom levels work, too) and the “shrunken tabs,” “truncated tabs,” or “trimmed tabs” (whatever you want to call it) goes away!

Although it appears the Shuar don’t practice the art of tsantsa anymore, it may not be a bad idea to keep this in mind if you ever find your SharePoint UI being visited by the spirits of their ancestors leaving behind a case of shrunken head.

Read Full Post »

Older Posts »