Sharepoint By Dummies

One of our users has a list where one of the fields is a multiline text field set to append new edits.  He wanted to be able to see all entries on that field in the view and to export it to Excel.

We found a link to how to display the entries inthe view, but unfortunately this stops the export working (it still shows in the actions menu but doesn’t export any data).  I have asked a question on Egghead Cafe to see if anyone there knows how we can export this information.

One of my colleagues pointed me to this page.  It shows a way to automatically populate form fields in an aspx page using parameters.

We use parameters from  controls a lot, mostly on filters for dataviews.  For an overview see my entry on putting the users name on an aspx page.  With this if you have a form on the same page (in the insert or edit template) you can automatically populate fields from controls on the page.  The only downside is that you have to select the values before opening the form.  Since you can also feed parameters from the URL used to call the page you can also use this to pull parameters from one page into the next.

We have found that this does not work on WSS 3.0 (aka Sharepoint 2007) as it produces an error when you try to save the form.  My colleague has implemented it on Sharepoint 2010 successfully.

Bought a new book on Sharepoint Workflows over the weekend, “Sharepoint Workflow In Action” by Phil Wickland.  I’ve been reading it today.  Interesting thing is that there’s a Kindle version as well as dead tree edition but Amazon don’t seem to offer the Kindle edition, to get the Kindle edition you have to buy the dead tree edition and then enter a code from a tabel printed on an insert in the front of the book. If you go direct to the publishers site then you can buy the Kindle version without buying the dead tree edition

I’ve been reading a bit of it today.  Might be useful.

Found a very useful link today:- http://blogs.msdn.com/b/uksharepoint/archive/2010/10/20/updated-permissions-permissions-spreadsheet-for-sharepoint-2010.aspx

This spreadsheet lists the out of the box permissions groups for Sharepoint 2010 and identifies which permissions it confers.  I downloaded it and added in the customer permissions groups we have so as to create a version for internal use.

One fly in the ointment, as far as we’re concerned, is that to create, view, edit or delete permissions groups in Sharepoint 2010 you have to be using the 2010 site master page (v4.master).   Unfortunately for application compatibility reasons we currently have to use the WSS 3.0 master page (default.master).

There are various things we often get asked to do with Sharepoint  which require functionality simply not available in a supportable way in Sharepoint (not even 2010).  I want to emphasise the word supportable there.  There are ways to fudge, cludge, bodge etc these things but they either work inconsistently or require you to do things that ensure that the system will not be supported and could fall apart if the servers ever get patched.  A previous administrator on one of our WSS 3.0 (aka Sharepoint 2007) sites implemented some things this way that means that we cannot migrate the site to Sharepoint 2010 without rebuilding it pretty much from the ground up (and will lose the functionality as you still can’t do it supportably in 2010).  The hosting supplier for some of our externally hosted sites said they cannot patch the server those sites are on without moving them to a dedicated farm because another customer on the same farm is using cludged functionality they know will break if they apply the patch.

Some features I’d like to see (here I’m looking at both Sharepoint and Sharepoint Designer):

• Run workflows at set time and date (with option to recurr).  We get a lot of requests for things that need this but haven’t found a way to do it in a supportable manner.  We’ve found a number of ways to cludge it but they’re not reliable and don’t persist over server reboots.  Basically we’re looking for a CRON/AT type functionality within Sharepoint.  This would only be relevant to Site workflows.
• Allow workflows to loop, in particular as a way to step through lists (encapsulating Document Libraries and similar as a special case of list).  Sometimes you want to step through a list and do something with each item, probably involving some sort of conditions (While {there are list items to process}, Where {condition is true} Do {some action} Until {end of list}).   Currently a site workflow can search a list for items where one field matches a certain value and process the first one it finds.  There are cludges to do this but they are unreliable and rely on the processing changing the fieldthat is matched on (else they’ll just keep hitting the same record).
• Array variable processing in workflows and parameters.  This links to the above item of looping, as you loop through the list you build an array which after you exit the loop you use in a subsequent action.
• Proper date arithmatic in workflows, filters and conditional formatting in XSLT views.  In workflows you can compare a date field to the current date or to some fixed date and get equals or not equals.  In filters and conditional formatting you can similarly compare to the current date or a fixed date but this adds in greater than or less than.  What you can’t do is compare to  X days before or after current date.  What we’re looking for is add the grater and less than comparison operators to workflow and add to all the ability to do arithmetic manipulation on what the field is being compared to.  There are a number of cludges for the arithmetic manipulation part,  mostly including a calculated field and comparing that to current date and they usually work but they’re inelegant and can be a maintenence nightmare.
• Nested groupings in filters and list comparisons (IN and NOT IN) in filters and increase maximum filter size.  Currently it is only possible have one level of grouping, you can’t have a group within a group.  A number of times we’ve run into situations where we have to have a filter which implements something like “(((field1=P1 OR field1=P2 OR field1=P3) AND field2 > [Current Date]) OR ((field1=P1 OR field1=P2 OR field1=P3) AND field2 is null AND (field3 < [CurrentDate] OR field4 = ‘TBC’))) AND field5 not equals ‘CLOSED’” where P1, P2 and P3 are parameters passed in from the URL or another part of the page.  This, as can be seen, requires nexted grouping and is quite large, easily blows the maximum filter size.  Adding in list comparison operators would shrink it somewhat (“field1=P1 OR field1=P2 OR field1=P3″ would become “field1 IN (P1,P2,P3)”) and if array processing was implemented would allow the option of parameter lists of arbitary size to be processed by passing a one dimensional array as the parameter.

An example of a customer request that would use many of these is:

On the 15th of each month after close of business (20:00) read the risk register.  Identify all risks which have not been updated in the past 30 days and the assignees and owners of those risks.  Send each risk assignee one email listing each risk they are assigned to that has not been updated in the past 30 days telling them to update them with actions taken since the last update within 5 working days.  Send each risk owner one email listing each risk they own that has not been updated in the past 30 days, identifying the assignee of each risk, asking them to ensure that the assignee updates the risk  within 5 working days.

With access to the backend database this is probably not too hard to do programmatically, but it can’t be done from within Sharepoint and SPD right now.