Remove Folder Creation Permissions

1. Go to the library within which you wish to restrict your terrible, naive users from making folders.
2. Access the advanced library settings.
3. Halfway down, there is an innocuous entry, called "Folders."
4. Set "Make 'New Folder' command available" to "NO."
5. Go for lunch, smug in the knowledge that you will never again spend three hours migrating hundreds of Ultra Key documents back and forth across folders due to user error.

Gotchas

1.  You can't do this by default.

Table of Contents Styling

Sharepoint is built, like Venice and other cities widely beloved yet reeking with sewage floodwater, mainly on itself and a swamp. It is less a piece of software than an ongoing, hierarchical conversation, maybe conducted with whips. Also like Venice, it periodically wets the broadloom for no apparent reason.

Table of Contents webparts are one of those less-baked parts of Sharepoint.

A TOC is handy. It lets you list subsites and key pages relatively easily, mainly by ticking tickyboxes, which tick nicely. The trouble comes with Sharepoint's file architecture, which is le dodgy below a few levels. Much as how the Quicklaunch/left navigation menu acts plain weird and sometimes disappears for no reason, the TOC is always displaying dynamic content, and will occasionally change how it displays with no warning whatsoever. This is irritating, because TOC pages are almost only ever needed when you are presenting an Important Portal Site that is supposed to fool someone familiar with paper into thinking they are not on the Internet. Sad face. Here is how to fix things randomly disappearing and or changing their style and or publicly breaking.

• The style sheet called Table of Contents Main contains no styles whatsoever for your table of contents.
• It styles columns.
• To style Table of Contents items, you must go to LevelStyle.xsl
• The margins have all been hard-coded, a level of grief that you are by now as accustomed to as Midwesterners are familiar with drought.
• If you go into LevelStyle.xsl, you can yank the inline margin-setting shenanigans. Thank Christ. You could also recode them there, probably, use what look like somewhat nifty variables which are totally fuckered by any kind of page layout work.
• Fuckered is a technical term.
• If you're creating a table of contents in a subsite that is further than one level from the top of the site (IE: Is already in [server:port]/first-level/second-level/ ), guess what?
• It will not display the pages as a nicely bulleted list. It simply treats the site itself and all the site's subfolders as an equivalent level.

SharePoint cannot handle anything deeper than a two-level architecture. Maybe three. That's when all its generative menu code breaks, so don't even bother. This means ... yes! XSL haxx. Yes it does. Hack at it. 

1. Copy the Vertical style template in LevelStyle.xsl
2. Paste and rename Vertical Bullet. 
1. This way, your many functional tables of contents will not be damaged.
3. Set the template name as follows, wiping the match="*" value because that'll bung your other pages.   <xsl:template name="VerticalBullet" match="Level[@LevelTemplate='VerticalBullet']">
4. Ax the span-tag to which the default styling applies.
5. Return to your main page.
6. Set your top level style to Vertical, and your second level to your new VerticalBullet style. The second level will instantly behave because there are no inline tags on the hunt for it any more.

Confirmation of the existence of the problem and source of where the levels styles can be found comes from here:

http://tomblog.insomniacminds.com/2007/10/12/sharepoint-branding-issues-table-of-contents-webpart/

Gist of my own XSL level styles, with CSS on top because you fully know you need to copypasta this into your own bizarre filestructure. Put the CSS in your CSS, put the XSL in wherever you store your XSL level styles. Then get a beer. I hope you have a bullet in your _layouts.

InfoPath WebParts Actually Easy To Use.

Having gotten VS2010 on the server up and running, know what it is time to do?

Throw it the fuck out the window and boot up InfoPath. It does all the shit you're trying - PAINSTAKINGLY! - to learn and do, except it does it better, smoother, and with an actual front end. It turns out that sometimes, things work out fine.

Note: there are totally ways to do this in VS2010, but who cares? Again, not you! YOU care about getting it done faster. And, it seems, totally accidentally following best practice. Surprise!

Here's how to make a form page that loads information straight to a list using InfoPath.

1. Go to Sharepoint, and, paying careful attention to the client spec, create a custom list on your site.
• Include appropriate column types - date, names, that sort of thing.
2. Go to the Pages directory of your relevant subsite.
3. Create a page to pull the list view into; list views can be webparts.
4. Edit the view of the webpart so the things you want are showing.
1. Click "edit webpart"
2. In the top part of the hideous pop-in frame there will be a link to "edit current view"
3. This will give you the library view editing interface for the webpart. Clickybox away.
5. Boot InfoPath.
6. Create New Form from Sharepoint List.
7. Enter the URL of your list.
8. In the form, turn off the Title field's mandatory little red star.
9. Delete the title field, unless you feel like turning it into an invoice number recorder.
10. Adjust your form as you like. 
• Reflect that Microsoft did this on purpose, released this as a separate product, and that it is probably fine.
• Wonder what has happened to your glorious, brutal temper in your old age. Perhaps you have mellowed.
11. Publish the form to the appropriate list.
12. Shut down your browser, restart, navigate to the page you made to contain your list.
• If you don't do this, it won't register the form's published existence.\
• Irritating red text for all.
13. Insert an Infopath webpart, which will automatically link to the list web part.
14. Turn on asynchronous loads.
15. Well what the fuck do you know, it worked on the first try and looks dandy.

Perhaps things are getting better in our old age! Maybe we can make a calendar webpart that calendars like a calendar next! Between this, the weather and the haircut, today is actually a-okay.

Visual Studio Can't Start SPUserCodeV4

The day has come at last. Fudging the numbers and being good with people will no longer spare you: it is time to actually do some actual wizarding, in a real IDE.

Horrors await.

First: I'm going through this with a paper book, from WROX, called "Beginning Sharepoint 2010 Development." It's been on my desk for the better part of two years as I put out fires and glared at Google and generally mucked about, but I thought hey, let's do this by the book!

So launch Visual Studio 2010.

Problem 1

You don't have Visual Studio 2010. You have Visual Studio 2007 and ... something Microsoft claims is free or possibly Express, yet insists has had its trial period expired. You need 2010, because there are no pre-established Sharepoint templates in any earlier version, and the odds of getting them to work from the internet are slim indeed. Acquire VS 2010. Make it work. Make someone else pay for it (and pay and pay, all shall pay)....

Build Your First Actual Piece of Code for This Benighted Thing

1. Launch VS2010.
2. Launch a new project, sandboxed as per best practices.
3. Insert a simple webpart.
4. Click "Build-Deploy" in order to make sure everything's hooked up properly.
1. Note that VS2010 has instantly thrown an error, related to SPUserCodeV4, which cannot be started.
2. http://blog.dennus.net/2009/11/18/sp2010-spusercodev4-your-new-web-part-project-isnt-deploying/ According to this, such is normal: You only need to start the service! Go to your central administration and start the service like he says. Except on your server, the service simply doesn't exist. It isn't there! There's no User Code service in place at all. 
3. That is because it is not called that any more, it is called Microsoft SharePoint Foundation Sandboxed Code Service.
4. This will tell you what to do http://stackoverflow.com/questions/3571787/sharepoint-2010-sandboxed-solution
5. The answer, which should be clear as day, is to go to Central Admin>System Settings>Manage User Solutions> "All sandboxed code runs on same machine as a request."
5. Click "Build-Deploy" again.
1. "Error Occured in Retract Solution".
2. Return to Central Admin.
3. Restart the web serv-
4. Gigantic runtime error. Apparently, the backend passwords do not match the passwords in Active Directory.
• What.
5. Go to your SysAdmin to fix it by resetting the password.
• Do not forget an offering of Snax. 
• Not actual Snax, those were disgusting, try walnut puffs.
6. Set-SPManagedAccount -UseExistingPassword
7. New password.
8. Return to Central Admin, start service. Service starts!
6. Click "Build-Deploy" again.

Good, everything's working. Now you can poke around happily in Visual Studio, getting a more and more serious sniff at how XML is used everywhere to... not maybe the best ends? This XML business seems pretty complicated, as all committee-driven simplifications inevitably are. The C# looks alright, deep within its safe wrapping of curvy brackets, magic words, and miscellaneous punctuation.

The multiple opening deploy errors have sapped my ability to care about this project. Perhaps if we forget about it for another 18 hours, things will go more smoothly on the build.

Fixing the Calendar With @media and Many Swears

The Sharepoint calendar system remains my closest friend and second most hated ally, after people who out people on facebook. It is super useful, after you train people to use it, which will take years and possibly a large carrot-shaped stick, one of the ugly ones that only vegans consume.

That being said, it has some weaknesses, one of which is printing. The thing used to print fine in 2007, but in 2010, someone applied misunderstood javascript magic to it, and now it simply doesn't go.

To add insult to injury, IE will override any javascript you write to fix it, no matter how beautifully you have applied the Modulo command.

Here is the fix.

1. Enter your CSS.
2. Dick with it until you're happy, here's some of mine, I assume that having patience with margin settings would help, and if you do it better let me know:

• These will more or less work when you go to print 
• in IE 7-9
• with your original window set to 100% 
• and your Print Preview window set to 60% 
• and your Orientation set to Landscape
• Yes, it certainly is a kludge, isn't it.
• But life isn't fair
• And it's almost patio season.

Remove Accidental Infopath Link to Visual Basic

SharePoint is designed to work in concert with other tools from Microsoft. This includes InfoPath, the bizarro-world form design program for people who hate nice things and love corporate business structures/XML. InfoPath allows you to make complex forms that launch poorly and need magic, special links to be edited in browser, and otherwise eat chunks of system resources so vast you would think Margaret Thatcher was still in power, but whatever, it's what you have.

Sometimes you will need to put special rules on fields in InfoPath, let's say when you want your submit buttons to disappear so your people cannot, say, save all their forms to desktop and overwrite other people's submissions and generally cause havoc within your system, triggering hundreds of workflows, none of which work quite right out of the box anyway.

To work with the Button you will be Custom Programming to Submit a form, you will open the Properties window. It contains a large trap within it, marked "Edit Form Code."

Your finger will slip. You are tired, it is raining. You will slip.

You will click "Edit Form Code."

Then, your system will wheeze to a halt as your form binds itself to the Damned, whichever variant of Visual Studio you have presently available. You will beat on the Cancel button like it is a bad pony, to no avail, and when you attempt to publish your form next, it will fail spectacularly to publish and insist on using the INFOPATH FILLER which is like unto the pit of despair.

Despair not!

Go to the Form Options.
Click Programming.
Click "Remove Code."

You're welcome.