Friday 24 December 2010

Setting permissions on a folder differently to the document library that contains it.

Had a support call come in that someone had lost access to a document library.  Turned out that what had happened was that one of my colleagues had been asked to make a folder in the document library 'secure', accessible only to a restricted group of people.  What he had done was to edit the permissions for the whole document library.

This request is actually pretty unusual for the sites we're running, We have been asked for 'secure' document libraries before but not to 'secure' a folder within a document library.

Securing a document library is done by selecting "Document Library Settings" from the Settings menu when in the Document Library then Manage Permissions  from the settings page that appears.

To do so for a folder first navigate to the parent folder of the folder you want to secure, so if the folder is DocLib\Parent\Child you would navigate to DocLib\Parent.  OPenh the Edit menu for the folder you wish to secure and select Manage Permissions.  This will open the permissions page for the folder.  Unless this folder has previously had it's permissions edited the only available menu will be Actiions.  You will need to open the Action menu and select Edit Permissions as it will be inheriting it's permissions from the parent folder.  This will cause the New menu to appear and will break the link between the permissions for the parent folder and those for this folder.  You can then add and remove users and groups via athe New and Actions menus.  If you change you mind you can also choose to return to inheriting the permissions from the parent folder, from the Actions menu.

Thursday 23 December 2010

To upgrade or not upgrade

Our main site right now is on SharePoint 2007 (WSS 3.0), no MOSS or other fun stuff.  At some point it will move to SharePoint 2010.  There has been a suggestion that we do that in the next couple of months.  Our concern is that we suspect that a number of our custom developments might not survive the migration, there are somethings we can do with ease on SharePoint 2007 that simply fail if we try to do them on 2010, for example graphical alerters in place of numeric fields.  Given the number of bespoke developments we have migrating could be a very painful experience and we don't have the luxury of downtime, the sites have to be available.

I did find a forum thread on LinkedIn that discusses the move.  It seems that there's a tool (STSADM) that will pick up most of the problems you're likely to face.

The thing is, most of the sites in our site collection (including the ones with the most bespoke development) will be getting archived in March/April/May 2011.  If we wait until after this has been done there will be a lot less to go wrong and to fix.  I have recommended that we wait until then.  Yes, 2007 is very out of date but we do not currently have any problems that would be fixed by going to 2010 or a business need for any features added in 2010.  We do have a 2010 site so if a new site came along we could build that on 2010 and if a site developed a need to move to 2010 we could transfer just that site over.

Thursday 9 December 2010

Displaying Server Parameters

My colleague discovered how to display a server variable (e.g. the logged on user) on a page:
  1. Insert a field from any list as a single item dataview, doesn't matter which list or which field, into your page.  We'll say you're using 'Title'
  2. Create a Parameter on that view of Parameter Type 'Server Variable' and set the Server Variable Name to the name of the variable you want to use (e.g. LOGON_VARIABLE for the username of the logged on user.
  3. In the page select the dataview you created then go to the Code view (or code pane in Split view).  look for a line that contains an at symbgol followd by the name of the field you chose.  If you used the title field it would look something like:
    <xsl:value-of select="@Title" />
  4. Replace the @ with a $ and the field name with the name of the parameter.  If the parameter name is Param1 the line will now look like:
    <xsl:value-of select="$Param1" />
  5. Save the page and view it in your browser, it should show your username.

Wednesday 17 November 2010

f#

Attended a presentation on Microsoft's new programming laguage, F# (pronounced Eff-Sharp, not Eff-Hash as some of my friends thought).  It's decsribed as like a better form of C# as it's Functional rather than Imperitive and doesn't have anywhere near the amount of 'boiler plate' that you need if you're writing code in C#/Java/C++/C.  As you can write code to add dunctionality to SharePoint in C# I asked if F# could be used for that as well, the almost ksh like way you can pipe things in F# seemed ideal for processing data entities such as list items in SharePoint so I couldn't see why not.  The guy from Microsoft didn't know.

Thursday 28 October 2010

Conditional Formatting bug in SharePoint Designer 2010

We have found a bug in Conditional Formatting in SharePoint 2010.  You set up the conditional formatting logic as you normally would and it just doesn't work (e.g. if you set up a Hide condition for certain circumstances it always hides).

If you click the Advanced button and look at the XPath information you'll see that the field names have been prepended with $thisNode/ and have an extra full stop (period) at the end.  To resolve this remove the extra text and magically it works!

Using Multiviews

Will update later but just wanted to stick this up as an aide memoirw: http://www.code-magazine.com/article.aspx?quickid=0709061&page=3

Thursday 14 October 2010

Creating piecharts in SharePoint

Having recently discovered how to produce bar charts from SharePoint data we have been getting requests for Pie Charts.  Bar charts are no great shakes, just an XSLT stylesheet controlling the relative width of two cells in a table, one with a coloured background and one with a transparent background, pie charts are altogether more complex (unless you have MOSS and so Excel services, but we don't).

Initially we found an article on EndUserSharePoint on how to do this using a service from Google.  This works well but has the disadvantage that the data has to be sent to Google's servers which then return the piechart so the user has to be connected to the internet and there's a chance of data leakage.

We then found a solutions for Secure Pie Charts on SharePoint which gets around this by using a solution from Yahoo!, storing the files locally and callugn them from some Javascript.  Well worth a look, I think.

We implemented it, I got it working on Monday and one of my colleagues struggled to get it implemented on Thuresday.  We eventually got it working but only when I remembered something else we had to edit to get it working, which isn't mentioned in the original blog entry (or if it is I missed it) and is easy to miss in the Javascript.

The below assumes that you have read the  blog entry linked above, downloaded the files, unpacked them as recommended and have the Javascript that calls the files open and ready to paste into the page in SharePoint Designer.  We tested this on Sharepoint 2007/WSS3.0 using Sharepoint Designer 2007 no warranty is given or implied, try it first on a test/sandpit server and if you screw up your production or any other server following these suggestions then it's your problem not ours. 

If you paste just the Javascript into a text editor before pasting it into the page the lines you need to edit are 27 (line 27 starts "<link rel="stylesheet" type="text/css" href=") through 39 to point to the local copies of the various files.  The original blog entry recommends putting the files in a document library (create one that isn't shown on the Quick list for this purpose) then using the "Copy Shortcut" on the Right-Click menu to get the URL to paste, I would recommend following that advice.  Then do the same for line 47 (setting the jQPath variable) with the path to jquery.js. but delete the filename leaving the final forward slash (so if the full shortcut is "https://myserver.org/resources/jquery.js" the line should read "var jQPath="https://myserver.org/resources/";).  The penultimate step is to edit line 123 to change the URL for charts.swf to the one for that file on your local server.

What caught us out the second time around is line 71 which sets the value of the variable chartkeyword.  Set this to the name of the field you are grouping by in the view.

Paste the resulting code into the Content Editor Web Part (use Code view) the original blog told you to put on the page, making sure to put it between the <![CDATA and ]] tags.  You should be ready to go and able to view the pie chart in IE.

If you can't see the chart first try pasting in the Javascript unedited then just changing line 71 to the name of the grouping field.  If that doesn't work check where you've pasted the code and you've used the correct field name.  If it does work recheck the various URLs ands change them one by one to the marching ones for your own server, retesting each time.  When it stops working that's the one you got wrong.

We found that initially after pasting in the code Sharepoint Designer 2007 crashed when we clicked back in the Display pane.  If this happens to you see if Microsoft Office Diagnostics starts up and if it does let it run and fix your installation.  This happened on 3 different machines so we figure there was some patch or fix that was missing (or possibly it was because we had Sharepoint Designer 2007 installed along side Office 2003 an there was some library mismatch).  If Microsoft Office Diagnostics doesn't start up make sure you're got the latest patchsets for SharePoint Designer 2007.

The question we're looking at now is if we can control the colours of the pie chart segments.  A number of the lists we're looking to have pie chart views on are for things that have colour coded statuses and that's what we want to display (how many red, how many amber and how many green).


This could be really cool and useful.

Friday 8 October 2010

ODBC connectivity to Sharepoint 2007

We were asked about getting an ODBC connection to Sharepoint for reporting purposes (i.e. using something like Crystal Reports or even a BI tool like Business Objects) to carry out reporting.  After some research it seems that you cannot use a generic ODBC connection to access Sharepoint, you can however use Microsoft Access to link to Sharepoint Lists and then use an ODBC connection to the Access database.  This does mean that you need to have Access on the machine and it adds an extra layer so it might be a bit slower than ODBC but it does at least give a solutions.

If the link is two way then this also opens up the opportunity to create 3rd party tools to update Sharepoint, possibly via a batch job, to keep another system in sync or to enforce business rules that Sharepoint lacks the sophistication to do.

Wednesday 6 October 2010

Need to dynamically filter a calendar view

We have a list of project risks where each item (i.e. Risk) is associated with one and only one project, each item also has a proximity date (i.e. roughly when we expect the risk to hit).  We have been asked to product a report page with a calendar view showing the risks against their proximity date with a dynamic filter that will let management select which project they want to view risks for.


Were this just a normal list view, no problem.  Just convert the list view to an XSLT DVWP in SharePoint Designer (or create the DVWP from scratch), drop a datasource and drop down box on the page and feed the selection into the filter on the view.  Job done.  Unfortunately it appears that you cannot convert a calendar to an XSLT DVWP and cannot find a way to create a Calendar DVWP from scratch.

We searched but the results either had nothing to do with what we wanted to do or were in the negative.

Posted this as a question in the Microsoft Sharepoint help forums.

Monday 4 October 2010

Linking Webparts

We have a report that is basically a bunch of dataviews in webparts pulled from various lists. Serveral of these have filters based on a text field selected via a dropdown.

All well and good until we needed to filter a dataview on fields that are not part of the dropdown. In database terms we neded to do an inline view so that the results of one query were the parameters of another. We were looking at Webpart connections as a possibility but documentation is not exactly abundant. I did find a YouTube video that explained how Webpart connections work and allowed me to work out the rest.

The process is:
  1. Open the .aspx page in Sharepoint Designer (this uses Sharepoint Designer 2007, other versions may differ)
  2. Create a webpart dataview to do the 'inline view'  sub-query, this only has the fields need for parameters for the filters on the main webpart dataview.  This will be referred to as the providor webpart and the main webpart dataview that displays the actual data will be referred to as the consumer webpart.
  3. Set any filters required, the result of this should be to return only one row of data for each value..
  4. Make sure that both webpart dataviews have a meaningful name.
  5. On the providor webpart open the "Common Dataview Tasks" menu and select Webpart Connections.
  6. A dialogue should open giving the name of the Providor Webpart as Source Webpart and 'Send Row of Data To' as the Source action.  The source action can be selected via a dropdown box in the lower part of the dialogue, leave it as 'Send Row of Data To' or change it to that if it has not defaulted to that.  Click Next.
  7. The next step give you the option of connecting to a webpart on the same page or another, select to use a webpart on the same page and click Next.
  8. You can now select the consumer web part in the Target WebPart drop down box.  In the Target Action select 'Get Parameters From'.  Click Next
  9. The next step will show a two column table in the lower part of the dialogue, the left column should be named "Columns in [Name of Providor WebPart]" and the right column should be named "Inputs to [Name of Consumer WebPart]".  In the right column there will be listed any existing parameters on the Comsumer WebPart (there may be just the default one of ListID) and at the bottom <create new parameter>.  Select <create new parameter>, the normal prameter creation box should appear.
  10. For each parameter you need create a parameter with a short but meaningful name.  The 'Parameter Source' drop down should be greyed out and the 'Default Value' should be blank, leave them as they are.  Once you have created your parameters click OK to return to the Webpart Connection dialogue.
  11. Your parameters should now be listed in the right column.  in the left column cell against each one click to select the cell, this will cause a drop down to appear.  Open the dropdown and select the field from the Providor WebPart that you want to populate the parameter.  Repeat for each parameter then click Next twice then finish to close out the dialogue.
  12. Now go to the Consumer webpart and open the Common DataView Tasks menu.  Select Filter.
  13. The normal filter dialogue will open and you can create the filters as normal but instead of creating the parameters you should select the parameters that you have just created.  Click OK to save the filters.
  14. You probably won't want to display the Providor webpart so select the table it is embedded in and open the Table Properties.  Set width and height to zero and click OK.  Finally, select the webpart and open WebPart Properties, open the Layout area and select hidden then OK.  The webpart will still be visible in Designer but won't be when the page is viewed in a browser.

Monday 23 August 2010

May have a partial fix to creating a filtered Dataview for "within the past 14 days"

It seems that if you create a regular view in Sharepoint and then open the .aspx file in SharePoint Designer you can convert the view to a DataView (an XSLT view). If the original view had a filter on it then that filter is carried over into the Dataview.

I tested this out and it does appear to work. The thing is that if you look at the filter it doesn't appear to say it's going to do what it actually does. The original filter was:
ImportantDate >= [Today] - 14
i.e. ImportantDate is after or is the date 14 days before today. The filter in the DataView is:
ImportantDate is greater than or equal to [Current Date]
i.e. ImportantDate is Today or a later date.

However, when the view is displayed it displays data for the past 14 days and future dates. So, on the one hand it's "Yay it works!" but on the other it's "I don't know why it works." The latter makes me very wary of putting it into production.

Resolved - " 'Edit Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater." error

One of our users reported a problem where they could open documents in Read-Only mode OK but if they tried to open them for edit they got an error message box, " 'Edit Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater.". They had IE 6 SP2 and Office 2003 so should be fine, but they were not.

After some research found Microsoft Knowledgebase article 833714 (and many forums and blog posts that linked to it) which contained a number methods to resolve this error message. We found that whilst their system claimed to have SharePoint support installed in the Office install it did not show as an add-on in IE. We removed and re-installed SharePoint support and they could open a document in edit mode.

We did also find a blog post that indicated that KB833714 doesn't always resolve this issue. The recommended resolution in that situation is to completely remove and re-install Office.

A number of the blog and forum posts identified the cause of the problem as the user has components from more then one version of Office installed (e.g. Office 2003 and OneNote 2007) and the older one installs a patch or update. This can result in older versions of DLLs being registered over newer versions. This may be the case here as this user had both Office Professional 2003 and Office Standard 2003, not exactly the same but close.

Thursday 19 August 2010

Export history of versioned field

Today's new puzzle involves a user who has a list where one of the elements is a multiline text field with "Append text to existing entries" (i.e. versioned field) used for an Audit trail. If you open an individual item you can see all entries made in that field. The view for that column displays only a 'View Entries' link for that column which when you click it opens the item and jumps to that field. If you export the view to Excel it only exports the most recent entry in that field.

The user wants to export the view and get all entries in the field.

UPDATE 1: Found solution for displaying all entries in an "Append text..." field. The resolution is to use a DataView in Sharepoint Designer and look in the code for the entry for the field you;re interested in then locate a line that looks like:

<xsl:value-of select="@Audit_x0020_trail_x0020_comments" disable-output-escaping="yes"/>


Where, in this case, @Audit_x0020_trail_x0020_comments is the name of the field. Replace this line with:

<SharePoint:AppendOnlyHistory runat="server" FieldName="Audit_x0020_trail_x0020_comments" ControlMode="Display" ItemId="{@ID}"/ >


Note that I had to drop the @ symbol from the field name else I got an error about an unhandled exception due to an Object Reference not being set.

This left two issues, one of which we've solved (or at least worked around) and the other we have not (actually there's a third one of how to get this past my boss who is wary of allowing things that involve direct editing of the code but if it's the only way it's the only way).

The solved issue is how to get a Dataview created in Sharepoint designer into the list of available views (labelled 'Views') at the right hand end of the Sharepoint List toolbar. Our workaround is to create a regular public view in Sharepoint then edit the resulting .aspx file in Sharepoint designer (delete the existing view and insert a Dataview, don't forget to go into Dataview Properties and check the Sharepoint List Toolbar checkbox).

The as yet unresolved issue is that if you try to export a Dataview to Excel it will only export the ID column and will give a message about Hidden or Read-Only columns that require data but have no defaults. One of the people commenting on the above linked site also reported this problem. Interestingly if we just create a dataview in a blank page, rather than putting it on an existing list page we get a different error message ("Unexpected error...your data could not be saved") and nothing gets exported at all! This also happens when we create a view with just the most basic of fields and no customisations.

UPDATE 2:

Posted a question about this to a help forum: http://www.go4sharepoint.com/Forum/export-excel-dataview-export-id-column-22860.aspx

UPDATE 3:

Just tested with a different list on a different subsite, got exactly the same results so it looks like it's not related to the list we're using or the fields on it (this list is just a text field and a date).

UPDATE 4:

Posted a question about this on Microsoft Technet. Had a reply, and follow ups, from someone.

Wednesday 18 August 2010

Still looking for that elusive filter

Still looking for a way to filter a DataSource on a date column in WSS 3.0. All the references I can find seem to make one or more of the following assumptions:

  • You want to filter for items where the date is the current date, we're looking for 14 days ago

  • You can write the code yourself in C# and upload it to the server, we're on a hosted service so cannot

  • You are running MOSS (Microsoft Office Sharepoint Server), we're running WSS



I did find something that looked promising maybe using conditional formatting but it didn't work out.

Tuesday 17 August 2010

Ordering books

In the hope of gaining some knowledge of SharePoint I've ordered some books:


Really struggling with this limiting the report to items within the last 14 days, as previously posted it'd be no problem if it was just a regular view on a list (just filter on '[Today] - 14') but because it's a Data Source that won't work.

Monday 16 August 2010

Show items for last 14 days

The site I've been tasked with looking after (or more precisely supporting the guy who looks after it) has a few pages that are basically reports generated via via data sources (I think they're like a 'canned query' or View (in Oracle terms) but are an ASPX item on a page rather than SQL or something sane like that).

We had a request in to amend one of these so it only shows items created in the last 14 days, the report goes to a meeting every fortnight so anything over 14 days old will have been dealt with at the last meeting. Were these regular SharePoint views, no problem. Just add a filter on the Created column for greater then of equal to [Today]-14 and we'd be fine. Unfortunately the data source interface apparently doesn't know about [Today] or doing calculations in queries. There is a parameter called [CurrentDate] which appears to return the current date (like [Today]) but it doesn't seem to work in calculations.

I did some Google searching and found a page part way there. In this case they basically put a calendar control on the page and created a filter for Created greater or equal to that. Set that 14 days in the past and it will have the same effect, but not what the user wanted.

In the end we had to work around it by putting a calculated field on the list items for Created + 14 and check that [CurrentDate] is less than or equal to that. Works but messy.

Another Assignment, another blog

As readers of my other blogs have probably twigged every time I start using a new type of technology or app I start a blog about it to as a place to talk about issues and an aide memoire for stuff I've found.

I'm now looking after a Sharepoint site.