Archives

Archives / 2004 / December
  • Creating or customizing Field Types

    Customizing SPS is sometimes a hassle. I'm not talking about customizing graphics or Frontpaging the pages into submission - I'm talking about extending the object model. Creating new templates for sites and lists, and so on. It's a hassle, which is why I'm always happy when things work out the way I expect them to. :)

  • Quick Tip: Erasing many Portal Areas.

    Erasing a Portal Area via the interface is a bit annoying - you go to the Manage Portal Site to get the Area Tree, right-click and Delete, then you have to confirm again, wait 10-15 seconds, then press another button to get back to the tree. If you're erasing a whole bunch of areas (on a development server, for instance, when you want to start a new batch of tests), it can take quite a bit of time and patience.

  • Creating or customizing Field Types

    Customizing SPS is sometimes a hassle. I'm not talking about customizing graphics or Frontpaging the pages into submission - I'm talking about extending the object model. Creating new templates for sites and lists, and so on. It's a hassle, which is why I'm always happy when things work out the way I expect them to. :)

  • SPS and Renaming AD Accounts

    We've been seeing some strange behaviour after we rename a group or user in the Active Directory:
     
    When we go to the Site Settings to define site-wide permissions, the old username is still displayed. If we remove it and then add it again, we see the new name in the Choose Group list - but after we add it, it's shown as the old group. Humorous, but harmless.
    The bigger problem is when you give such a group permissions on a specific area or list. If we try to remove the old name from the permissions list, we get an ID Not Found error . When we try to add the new group to the permissions list, we get a Group Not Found error.
     
    All this is caused by SPS storing user data in the UserInfo table in the DB - it caches the old usernames, and for some reason uses that as the key when trying to add/remove groups to Areas, rather than the SID (which is also saved for every entry).
     
    The solution we found for this was to manually change the UserInfo entry, or better yet - erase it and let SPS recreate it when we add the group again. Naturally, it's not something we want to be doing in a production DB. Another minus is that the ACLs for various areas and lists point to the UserInfo row, not directly to the AD. This is a good thing generally, but means that once we erase the old entry, it's erased from all ACLs - we have to go and give that group/user permissions again. If this is a working server, we probably don't want to do that, and we'll just change the tp_Login field - leaving room for typos and human error.
     
    Anyone know why SPS doesn't re-cache the Username from the AD when it changes? It DOES keep the SID for each entry, so it does have the AD entity's unique key - it should use this, and keep the Login name purely as a cache.
     

  • Web Part Versioning

    If you have a web-part on your development machine that occasionaly decides to die - give you Not Marked As Safe errors even though it is, and requires removal and readding for it to work (with no other steps necessary), you may have a version mismatch.