If you’ve ever used the OOTB publishing approval workflow, you will know that it’s pretty good and easy. But, if you’ve ever had some slightly niche requirements, then you may have had an absolute nightmare trying to figure out how to implement it!
If you want to do some customisation, like route the approval task to different groups for different items, then you will need to make a new workflow. So you can copy the OOTB one and add in a lookup of some kind to set the Approver field. Great, that was easy! Sure was easy, and that shouldn’t really affect anything should it? You give it a test and discover that approving your task didn’t affect the actual list item’s approval status. Huh. Oh well that makes sense, because you normally set that when creating the workflow…but that is on the site. There must be a setting in Designer. Oh. There isn’t. Never fear! We can add in some steps to the workflow to set it. Take that Designer, I have bested you! You test again and it works like a charm. But then you think, what if you just approve the item from within the list, rather than the task you have been assigned? You guessed it, it doesn’t stop the workflow. WHAT?! Argh!
Eventually, you land at the solution. I will have my custom workflow, but I will control it through event receivers. I will start it and end it, I will set the approval status, it will all happen through event receivers. That is kind of annoying to set up, let’s not kid ourselves, but unless someone else can shed some amazing insight onto this, that is the way to do it.
There is one other thing to note about custom workflows. They are necessary when you want to refer to a custom field in a list. So if you thought you could be clever and use the OOTB workflow and have a field on the item that is the Approver group to route to, then you are sadly mistaken. I haven’t tried it, but apparently you can limit a workflow to a content type and so could put the field you want in a content type and then have your list inherit that. In theory that should allow the OOTB workflow.
So here is a gotcha that was discovered at work in the last week…it appears that content types don’t just inherit, they also pass properties back up to their parents! Essentially, I had a content type that was being used for a list. The content type inherited from built-in property types, you know the deal Document from Item type thing. Anyway, there was a request to update the compulsory Title field in the list to be ‘Surname’ instead. Simple enough you would think. Well, it is and it isn’t. If you try to be a good little developer and think that you will update the content type because you might use it again and you will want it to be ‘Surname’ there too, well, you would be wrong. This is what was done, but then ‘Surname’ was popping up all over the place! It turns out that it had sent that edit of the field name back up it’s inheritance and sent them all through the site. The correct way to apply the change is on the List Settings for the specific list where you want to change the Title display name.
A site I was working on recently involved applying a new colour theme as part of a rebuild of an existing site. I was given a base colour and was then required to put in place gradients, and various other shades of that colour at points (think :hov etc). I was then asked to change from the colour I was given to another, and then another. I did what any sane person would, and turned to the internet for help. Unfortunately, I found that despite the wealth of easily found tools for creating palettes of complementary colours and converting hex to rgb and a whole manner of things, I could not find what I wanted. All I wanted was to enter a colour, and get increments of that colour that were lighter and darker all the way to white and black.
Given all my searching had failed me, I decided I would have no choice but to implement this tool myself! And actually, what a fun little task to do. Now, I must stress that this was made with the intent of giving me what I needed as quickly as possible. Consequently, it is imperfect, ugly, and perhaps a little inelegant. However, that can all be changed down the line, what it does do though is meet the exact specification of what I needed!
I work with Microsoft SharePoint and have come to know it as a system designed for end users first and developers can ‘work it out!’ That is probably a harsh criticism, I’m sure all developers get annoyed at certain elements of the technology they work with. This is one particular thing that came up and drove me insane until I discovered what was happening.
I was writing a CAML query that included passing in the Title of the page as a parameter, but kept getting no results despite being sure that the query was correct. I could see the fields in SharePoint that should return, but alas the empty set kept coming back. After too long searching I was able to finally find the truth. When adding a Term to the Term Store, if it includes an ampersand (&), SharePoint (in its infinite wisdom) decides to convert that to a wide ampersand (＆).
Given my CAML query was taking in a parameter dynamically that included an ampersand on some occasions, I needed to replace these whenever they arose. I had to write a little regex to alter my CAML query before it was executed to substitute in wide ampersands for any regular ampersands. This was essentially:
Regex rgx = new Regex("&");
string text = "My CAML query";
text = rgx.Replace(text, "\uff06");
I find it incredible that the approach taken is to adjust the ampersand in Term Store entries, but not elsewhere on SharePoint (basically begging for this issue to arise), so be aware of the devilish ways of Microsoft and in particular SharePoint!