I’ve been having some more fun with Site Provisioning.  I have a requirement that in my Prov code I need to alter groups.  For most of my work I’ve been altering RoleAssignments in SPWebs with no trouble, however I came to do the same with a list as in an SPWeb.

Now I’m not sure if you can do security in the ONET but for my requirements I have $Resources that need concatenating together to form the group names (don’t ask).  Which it can’t do so it has to be done as a site provisioning thing.

What I noticed though is in my list, "of parent SPWEb of Parent SPWeb(RootWeb)" things where not as they were supposed to be.

The security on the list was completely wrong, as in it stated it had Unique permissions, when actually it does not, it will have when I’m finished with it, but at Site Provisioning time it should not.  Also all the groups were relating to the Site Collection level not the custom groups of the sub site it should have inherited.

It’s as if none of the list processing for fixing up the security on the list has happened, as it had done previously on SPWeb objects.

After Large amounts of digging I found that at time of Site Provisioning the List.Update() method has not been called. Calling this on the list before I do my processing, resolves all security issues.

So if having trouble provisioning list security remember the lists still in flux till you call the Update, whereas the SPWeb objects are not.  Weird, but true.

Technorati Tags: ,,
Advertisements