You are currently browsing the category archive for the ‘SharePoint Designer 2007’ category.
Issue: Using repeating tables in InfoPath is a great approach to capturing repetitive data on a form. However when you want to display the information contained in the form on a SharePoint list or web page, a few caveats come into play.
Let’s say you want to display information contained in the repeating table on a web page. When you design the InfoPath form you only have the options to display each field as either the first, last, count or merge (see image below).
This is not an issue if you are content to simply display the merged contents of the repeating table. But let’s say that you want to use the web page for something more than just displaying static data. For example; you might want to edit the page in SharePoint Designer and insert some conditional formatting. Having data merged into one cell/line might not work for your display requirements. In this instance you will need a unique line for each item in the table displayed on the list.
So how do you submit the rows of a repeating table in InfoPath to a SharePoint list? There is no easy method of doing this (specifically crafted my MS). I have found a few alternatives but most require code and are not for the beginner.
The Visual Basic code and the UpdateListItems method is one of the best methods I’ve come across so far. I have followed these instructions and got this to work. However a lack of time and knowledge of VB prevented me from getting more than basic fields to work.
For my requirements I tried another approach. This might seem long winded but it worked for me. I created a SQL database with all the fields I needed in the InfoPath form. I then designed the InfoPath form from the SQL database and published it to a SharePoint site. This form had 2 data connections – 1 to the SQL database and 1 to the SharePoint library.
Users go to the SharePoint library to open, complete and submit the form. The form (for record purposes) is saved in the library. A copy of the data is also submitted to the SQL database. Each item/line in the repeating table is stored as a unique line in the database.
On a new web page on the SharePoint site I inserted a dataview web part and connected it to the SQL db. I then ordered the fields as appropriate and applied some conditional formatting so that the page could be used as an overview or management page.
The immediate downside of this approach is you cannot edit the information in the SQL db directly by opening up the form again and re-submitting the data. I have not found out how to do this yet!
To be able to edit the data, open the web page with the dataview web part on it in SharePoint Designer and go into the web part properties section. Make sure to tick both the ‘show edit items links’ and ‘synchronize commands’ boxes (see below).
This will provide an ‘edit’ link on the dataview web part (see below). You can then edit the information in the list and have the changes synched in the SQL db.
Hope this info helps…
Situation
Workflow created in SPD and set up to activate upon the receipt of a new item being created in an emailed enabled list. Worked fine before SP1 was installed
Issue
When the email was received in the list, the workflow did not automatically start. The workflow worked fine if started manually. I had read that this action was disabled by design in SP1, but had also read that there would be a fix in the infrastructure update. After applying this the issue remained.
Resolution
Bit of digging unearthed this link which breaks down why this all happended. Suffice to say that running the command "stsadm.exe –o setproperty –propertyname declarativeworkflowautostartonemailenabled –propertyvalue yes" worked on my farm. Check this out first on your test hardware.
UPDATE: Just migrated my farm onto new hardware and could not get the above command to work on the new web front ends. This version did the trick;
stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true
I also found that I had to turn off allowing each document library to recieve e-mail and then back on again to get it to work on the new server. This was of course after I changed all the email settings to reflect the new server details.
The font used by default in emails generated by SharePoint Designer workflow is Times New Roman and can look out of place in today’s corporate environments. It appears that there are no obvious ways around this in the workflow gui.
Chancing my arm, I tried basic html to change the font type, size and colour, coupled with tages for hyperlinks and it worked a charm. I also came across this blog post afterwards which covers some of the same ground.
I have recently been using one of the four Microsoft sample master pages as a starting point for customising a new corporate site. After many hours and days I finally picked apart the style sheets and got it to look right for the business. However this has all come crashing down because the base custom templates supplied seem not to allow printing of the main body of the page - only the top third will print. I’m no delveloper and so far have not been able to fathom out why this is happening. I have confirmed that this is also the case with all the templates except the Reverse one – which prints just fine.
I’ve had this more or less confirmed by MS and I’m awaiting confirmation if they will release any alterations. For now then it’s back to square one. If anyone else has come up against this then let me know. I could not find much talk about this at all.
Been doing some work involving lists, workflow and reminders and cam across this great article on setting up workflow reminders. I had an issue with the ‘Pause Until Date’ wokflow command and testing it out. It just paused and did not go onto the next step.
I got around this by using the ‘Wait for Field to change’ command instead and used a different methodology. If anyone’s had issues with using the ‘Pause Until Date’ I’d like to here about it!
I have since found that this is an actual fault and is fixed in SP1
Copying a workflow from one list to another is a pain even in the same site. If you have lots of steps and all you want to do is change fields in each of them then it might be quicker to do this than start from scratch.
I just opened the XOML in notepad and copied it’s contents into the XOML file of the new workflow (see step 3 in link). Then I copied across the *file*.xoml.wfconfig.xml and *file*.xoml.rules files and then went in an edited the workflow normally in SPD. Bit of a pain so if you don’t have a complicated workflow it might be easier to start from scratch.
