My fellow workerbees work on Projects, so we have a Create Project custom webpart that asks a new Project Manager a bunch of questions (project name, square root of 57, the airspeed of a swallow) and programmatically creates an SPWeb from a custom template with all of the appropriate doclibs, lists, etc already set up. We don't want non-project team members messing up other people's work, so the webpart automatically breaks permission inheritance. Employees can see almost everything, but some stuff is double super-secret, so the site template includes a Sensitive doclib which the webpart automagically changes to only allow team members to see its contents. Of course, the Project Manager can manually set special permissions on a library or item basis.
So far, so good, but eventually even the most tenacious project comes to an end, and regulatory considerations require that when a project closes, we must keep the entire project page intact, but still guarantee that nobody, I mean nobody, can modify anything in the project. Well, a system administrator can, but that's it.
The twist is that if a particular bee had read access to a page, subpage, list, or item, s/he should still have read access after the project closes. If s/he didn't have read access before, s/he still shouldn't after the project closes. However, (almost) everybody who had write/delete access of any kind needs to lose it.
My first thought was to walk through each Role Definition of each Role Assignment on the page and turn off the appropriate edit/delete bits in BasePermissions, then repeat for each list with unique permissions, and each list item with unique permissions, then recurse through each subsite and repeat the process. Doesn't work. Yes, the debugger tells me the permissions changed. Yes, I'm calling Update(). Yes, I'm setting AllowUnsafeUpdates to true. Yes, no errors are generated. But when push comes to shove and I look at the permissions via site settings, nothing has changed.
I see plenty of examples out there of how to set things up initially, but I can't find a single example of programmatically removing selected permissions after they're already set up. Am I even approaching the problem correctly? Should I be creating custom Role Definitions and then modifying them on close, instead of modifying Contributors and Readers? If so, how do I allow the Project Manager to assign team members to the custom Role Definitions but prevent her from assigning them to Contributors and Readers?
cwogle