The tag line includes “…we find frustrating” for a reason. Every now and then, SharePoint presents you with a situation that just makes you scratch your head. Here’s the most recent one for me: There is a setting on the People and Groups column where you can specify that multiple people or groups are allowed. However, if you are filtering on a people and groups column, you can’t use the “contains” operator. I can imagine that since “contains” invokes a string function, it would be more work to implement it on people, and I can further imagine a developer saying: “if they want to filter on multiple people, they can use a group.” However, a group doesn’t work for us.
We have an Internet-facing site for our business partners, and we also include a section for employees who may need to access company content when they are away from a machine that can establish a VPN connection. This site is on a separate farm, and a separate domain. Our internal domain users can authenticate via an Active Directory Trust, so, in theory they only have to remember one set of credentials. The problem is, they have to include the domain name, so they log in like “co-domain\jsmith” which is a little annoying, particularly if you’re using an iPad. If they don’t mind maintaining two UserIDs, they can use credentials from the outside domain, in which case they could log in as “jsmith”. As you can imagine, this is easier sometimes, but not always. If I am on my domain laptop, it’s easier to be “inside me.” Normally, it doesn’t matter who you are, because we establish permissions for both. Of course, since I said this was frustrating, you realize I’m not talking about a normal situation.
In trying to support a company Wellness Program, we are building a site where employees get points for doing healthy things. They can redeem these points for awards. In addition, the program administrator can redeem their points for them. This combination of activity means that the Points and Redemptions list has items “Created by” an internal domain user, an external domain user and the administrator. OK, we aren’t filtering on that when we want to show the employee their own point balance. Our first attempt at setting up a filter mechanism was to put both userIDs in a People column of an Employee list and filter on “Domain Names contains [Me]” – no can do. To get around this, we created two columns in the Employee list in addition to a name column (“John Smith”), we have a trusted ID “co-domain\jsmith” and an outside domain column “jsmith”. We pick using the name, and a workflow populates the domain versions wherever they might be needed later. When we want to filter, we select: outside domain user = [Me] OR inside user = [Me].
I would be willing to bet that some of you have already thought of a better way to solve my problem than the brute force approach I took. If you have, please add a comment. However, if you follow this blog, you know that I don’t try to teach people how to do things here; this blog is more about why we do things. Why did I (have the person actually building the site) go to all this trouble? So we could absorb the frustration at this level.
We could have simply said “when you visit the Wellness site to enter points, you must use your co-domain credentials;” in fact, I’ve done things like that before – I know better now. We have to build this site once; people have to use it every day. I can’t begin to count the times I’ve have had to remind myself, and other programmers of that (1:n) ratio over the course of my career. No system, platform, device or language is perfect; automated systems will always include pain points and frustration. Good architects, designers and developers remove these before deploying a solution; they absorb the pain and frustration into the solution. When we deploy the Wellness site, it won’t be pretty under the hood, it will include this somewhat hard-coded kludge of name variants, but it will work like the employees expect. No matter how they login, they will see their points.