Some Sharepoint Stuff

In my real job, I do a bit of Sharepoint support, not much development, so I don't really get to work with the dotNet side of things.

I do get to work with the database, which gives quite a bit of insight on how Sharepoint works internally.

One of the things stored in the Sharepoint database is the individual settings for each webpart.

Now, our client has a Sharepoint based site, with some custom dotNet stuff thrown into the defaut.aspx of the template's web Homepage. This Homepage really gives us headaches because some users have the ability to close webparts. This could be easily fixed by getting into the Modify view, but something with the additional code prevents Modify view from working.

What happens is when you place the web in Modify mode, the browser gets stuck and stops responding, and CPU usage goes up. I've debugged it and partially traced it to an infinite loop in the resize functions in Sharepoint's Javascript code.

I'm not too eager just yet to go messing around with the dotNet code, as some loaded controls might be involved in messing up the page's DOM heirarchy or something that could cause an infinite loop.

To restore the missing webpart, we have a backup default.aspx of the vanilla Sharepoint web Hompage which we use to temporarily replace the dotNet-messed-up one.

With the vanilla page in place we can safely call Modify mode and restore the webpart.

Now I was asked how we could prevent users from closing the webpart accidentally, and one of the things that came up was to disable the close button. This can only be done in Modify mode, which requires the vanilla page, which requires that no one is using the site, which can only be done during non-business hours.

With a global user base, and a shift nearly opposite to the business users, the window where we can use the vanilla page to do our stuff is only 2-3 hours. Coupled with the fact that there are hundreds of sites to change, it begins to be impractical.

So with some determination I set out to find where Sharepoint stored the settings for webparts, and the field tp_AllUsersProperties seemed to invite further investigation. It's an image field, used to store an arbitrarily large binary value. Here is what I have so far:

"Header" - Always present: Doesn't seem to change
0105 0000 0002 2A00 4A00 2900 033D 0000 022A 0049 0029 0003 3E00 0001

"Separator" - Seems to separate entities
0F01

"Close Disabled" - Present if "Allow Close" is unchecked.
15 0029 0003 4800

"Zone Change Disabled" - Present if "Allow Zone Change" is unchecked
2B 0029 0003 4800

"Minimise Disabled" - Present if "Allow Minimise" is unchecked.
16 0029 0003 4800

Description - Text
02 0029 0003 FFFF nn

nn is the length of the text in bytes, no null termination

Detail Link - URL
1A 0029 0003 FFFF nn

nn is the length of the text in bytes, no null termination

Help Link - URL
1B 0029 0003 FFFF nn

nn is the length of the text in bytes, no null termination

Icon (Small) - Image URL
1F 0029 0003 FFFF nn

nn is the length of the text in bytes, no null termination

Missing Assembly - Text
27 0029 0003 FFFF nn

nn is the length of the text in bytes, no null termination

Icon (Large) - Image URL
20 0029 0003 FFFF nn

nn is the length of the text in bytes, no null termination

"EOF" - Always appears at the end
0F0F

It only seems to encode the Advanced Settings.

If it is null, default settings are used when in Modify mode.

If no text entities are defined, there must be at least one text entity before the EOF marker. The entity can be any text entity such as Detail but it should be truncated as:

1A 0029 00

each entity is followed by the separator, unless it is the last entity, where is will be followed by the EOF marker.

If entities have an identifier (first byte), a robust parser should be able to read the entities even if they were written in any order, unless it expects an order in which they are written.

nn is only a byte wide so the maximum number of characters in the text entities is 255.

Having incorrect values results in an error with Sharepoint not being able to "serialize" the webpart.

I have no idea what the recurring values "0029 0003 FFFF" mean. Changing them results in the same error as above.

I haven't tried this on another Sharepoint, or across multiple sites.

You should join tp_PagerUrlId to the Docs table in order to find the page that the webpart is on.

tp_WebPartId ias actually a GUID of a hash of the webpart name. See about that here.

As we are looking to eliminate the ability to Modify I've since moved on to more simpler Javascript to hide the webparts Modify buttons.

Anyway, I hope this is useful to somebody.