performing admin tasks by typical users

when developing sharepoint web parts and applications, we use the object model and implement the public functions, etc that are available to us...after all there is quite a bit that are available and most are very useful.

what the documentation doesn't always do a good job of, however, is telling us *who* can perform the task.  this is a common theme i see when working with customers and one i hit in my first sharepoint development project *way too late* in the game...we had to completely re-write areas because we made several key assumptions.

developers typically run under administrator privileges in their dev boxes and environments.  i'd imagine any sharepoint dev is an admin or at least a site owner on the sharepoint site they are working on...maybe this isn't always the best way of doing things in development (see andrew duthie's thoughts on least privilege).

similar development caution should be used when writing web parts.  patrick points to this article regarding some impersonation techniques to ensure that you can “get around” some of these issues.  i'd take it one step further and tell you that one thing we did in some instances was to make the sharepoint application pool account the administrator user (either a box admin or part of the portal admin group).  this way rather than maintain our security credentials for a domain user in clear text (in order to use impersonation of a named account in the example you have to), our impersonation code simply “reverts” to the process user (which just so happens to be a user with appropriate privileges), then when done...we just revert back.

good stuff.