Wednesday, May 27, 2015
All the articles I found relating to filtering by a DateTime seemed to hard-code a date. I.e. ...$filter=SomeDateField eq DateTime'2015-05-27T00:00:00Z'... which is fine and works but if you are filtering using DateTime variable (because you are applying some sort of date transformation) then it is difficult to find anything about how to do this.
Turns out when you add your filter date variable to the above example, you need to change the 'Return field as:' setting from "String" to "ISO Formatted".
So the above example would look something like:
...$filter=SomeDateField eq DateTime'[%Variable:FilterDate%]'... and when you add that variable you select to return the contents as ISO Formatted.
NOTE: Just incase, you cannot just type in the bit of code in the [%..%] section, you need to use the "Add or Change Lookup" button in the String Builder dialog.
Hope this saves someone else some time.
Sunday, March 2, 2014
I've finally had a bug registered for this by Microsoft. It took nearly 4 months mind you.
Tuesday, September 24, 2013
OK, firstly, if you didn't know, SP2010 had a bug in the ddwrt:FormatDate function in XSLT where it assumes that you always use Locale: English (US). So if you live in any other part of the world you can't use this function.
Well, thanks to a bunch of other people and their posts, here, here, and kinda here, there is a way around this using even more XSLT.
So for me, I was calculating differences between dates using strings (yeah I know, probably not the best way but...) and because my Australian Dates were all over the place but I was always calculating them using yyyyMMdd I modified Elio's template for my own.
Hope this helps others, at least as a starting point. Oh yeah, and I hope one of these days MS get around to fixing the root cause!
<!-- ***************************************************************************** -->
<!-- This template fixes an issue where the US think they are the only ones on earth -->
<!-- NOTE: Returns date in yyyyMMdd -->
<!-- If you went to town implementing string manipulation templates to parse a date format out of a parameter you would -->
<!-- be able to return any formatted date, but I don't have the time at the moment -->
<xsl:param name="dateValue" />
<xsl:param name="monthFormat" />
<xsl:param name="locale" select="3081" />
<!-- Split Date -->
<xsl:variable name="day" select="substring-before($dateValue, '/')" />
<xsl:variable name="month" select="substring(substring-after($dateValue, '/'), 1, 2)" />
<xsl:variable name="year" select="substring(substring-after(substring-after($dateValue, '/'), '/'), 1, 4)" />
<!-- Create US Date Format -->
<xsl:value-of select="$month" />/<xsl:value-of select="$day" />/<xsl:value-of select="$year" />
<!-- Month Notation -->
<xsl:value-of select="$month" />
<xsl:value-of select="ddwrt:FormatDateTime($USDate, $locale, 'MMM')" />
<xsl:value-of select="ddwrt:FormatDateTime($USDate, $locale, 'MMMM')" />
<xsl:when test="string-length($day) = 1">0</xsl:when>
<xsl:value-of select="$day" />
<!-- Create Date -->
<xsl:value-of select="$year" /><xsl:value-of select="$monthString" /><xsl:value-of select="$twoDigitDay" />
Thursday, September 19, 2013
Recently I was building a new SP2013 site using the same techniques we had developed for SP2010, namely composite pages using query string parameters to filter on Master / Detail records. But we discovered that the filtering web parts were not filtering!
To get to the point, after much search around, turns out that for this feature to work, you need to ensure the ‘Server Render’ checkbox is enabled in the Miscellaneous section of the consuming web part.
To go even further, I would say that this field needs to be set for more than just this feature to work. XSLT doesn’t work properly if this isn’t enabled, and I’m sure there are other things that when they don’t work, will trace their roots back to this checkbox.
Thursday, September 5, 2013
Although classic mode authentication is supported in SharePoint 2013, in reality you can only really use Claims. Workflow Manager 1.0 requires Claims-based authentication otherwise you will see all sorts of errors.