I’ve been working on a SharePoint project for work for the past few months, and I’m getting close to the “go-live” date. Actually, it’ll go live whenever I’m “done” (whenever that will be…).
But that’s beside the point.
The point is that I’m becoming less and less impressed with SharePoint as a development platform. And I didn’t start out with a great love for it in the first place.
Perhaps it’s because I’m constrained to only using SharePoint Designer. No .NET code allowed on the site I’m working on. That bums me out right there, since I consider myself a great .NET developer.
Most of my work has revolved around customizing SharePoint lists, and using SharePoint Designer to create custom workflows to support the operations of the team I’m developing this for. Not necessarily hard, but the requirements have been challenging to implement, to put it nicely.
One main requirement, as it turns out, isn’t really possible to implement fully in SharePoint, at least in a nice way. There are two groups of people who are responsible for different items (a.k.a. “fields” or “columns”) in a list. One group, let’s call them “Group A”, doesn’t want the other group (“Group B”) to be able to modify Group A’s fields.
Now let me stop right there! I understand that SharePoint is a “collaboration” tool, so preventing users from collaborating just doesn’t jibe with the core of SharePoint. That’s pretty much the crux of the problem.
If it were possible to set permissions on the field level, this blog entry would not be needed. But it is not possible to restrict access to only certain fields in a list to a certain group of people, so I had to think of ways to enable this functionality, and the way I came up with is sub-par at best.
I ended up creating 3 lists: one for Group A, one for Group B, and one which shadows Group B’s list. Then there are workflows which copy Group A’s fields in Group A’s list to Group B’s list, and Group B’s fields in Group B’s list to Group A’s list. The “shadow copy” list is there to prevent the workflows from running in an infinite loop—the items are only copied back to Group A’s list if they are different between Group B’s list and the shadow copy list.
As it turns out, this is not without problems, since if someone in Group A modifies one of Group B’s fields in Group A’s list (did you follow that?) then it will remain out of sync with Group B’s list, since Group B’s fields aren’t copied from Group A’s list to Group B’s list.
As it turned out, thankfully, this wasn’t as big of an issue for this particular solution (whew!).
It was my intent to set permissions on the lists such that people in Group A only had read access to Group B’s list, and vice versa. However, as it turns out, the workflows will fail to copy data since they run as the user who initiates the change to the list. So when a Group A person changes an item in Group A’s list, the workflow tries to copy that change to Group B’s list but can’t because Group A only has read-only access to Group B’s list.
So I thought I could change the permission to allow Group A to edit Group B’s list, but then just set the “Hide from browsers” property on Group B’s list so that Group A couldn’t find it when browsing the site. So instead of preventing a modification of Group B’s list through the use of SharePoint Permissions, I would be preventing the modification of Group B’s list by making it very hard to find the list. Problem solved!
Not.
Once again SwearPoint, er, SharePoint worked against me, and here’s how:
If you set the “Hide from browsers” property on the list, it does, in fact, hide the list from site when you click on the “Lists” or “All Site Content” links in SharePoint. HOWEVER, it also hides the list from workflows!
[UPDATE: The list’s name is the only thing hidden from the workflow. The error I was seeing which led me to the previous conclusion was due to a user-error (and, no, I wasn’t the user!). The workflow continues to operate successfully if the referenced list is hidden.]
So my final solution still has three lists, one for each group and a third to ensure that the workflows eventually stop, and each group can see the other group’s lists. Not at all what I set out to accomplish!
It’ll just have to be a training issue to keep each group out of the other’s list.
So much for collaboration (at least in this project).
Posts
