How To Remove Drop-Off Libraries

As previously discussed, Sharepoint automatically creates a tin-eared list of nonsense whenever you turn on or change any aspect of its development. Some of this stuff looks useful when it arrives, and my favourite of these is the drop-off library.

Why Remove The Drop-Off Library
Drop-off libraries are supposed to be document routing catchment basins. People upload a document and fill out some metadata, Sharepoint routes the docs according to rules set up by the admin who runs the thing. The documents go to somewhere retrievable, possibly for long-term storage. It relies on computers doing things automatically, which sounds fantastic and should work really well.

Sadly, should you set up a drop library to accept a document in an anonymous way, then someone uploads the document without metadata, the upload won't fail.

No. It will upload a doc without metadata, kick the event handler, and leave the doc in the library, issuing No-Metadata warnings periodically. Should someone then fill in the metadata, the event handler then does not re-kick. No. The document simply becomes public to whomever can see the thing. Approving it also does not kick the handler. The handler is asleep. The content router is therefore of only moderate use; you will be writing your own event handlers and your own Byzantine submission guidelines, or you will be hand-picking your permissions settings.

In cases where you've been asked to do both of these things, you will want to get rid of the drop-off library.

The Drop-Off Library is protected and comes sans the Delete This Library link. Which you need.

There are a number of blog posts on the internet about how this is very straightforward, as you can use the Client Object Model, PowerShell, or Sharepoint Manager 201x to do this chore, which must be clear to people who have been administering MS products for more than three years, but I assure you is not to the rest of us.

What is the Client Object Model?
As far as I am aware, an object model is what you use to describe the construction plans and dependencies for your software. There are twenty links under Microsoft's USING THE CLIENT OBJECT MODEL page, one of which is "Creating Windows Console Managed Client Object Model Applications," none of which are "Open a CMD browser (on relevant machine/on local machine) (screencap) and type "sudo drop (relevant-path)
ARE YOU SURE -p
YES"

Good luck learning things of use on a deadline there.

What is PowerShell?
Microsoft appears to have re-written the command line to include... cmdlets. Also a vast portal on the greatness of PowerShell. Possibly, if you already know PowerShell, or any shell, this will be useful to you. But I have twenty minutes to get rid of a load of drop libraries. This is not useful either.

Sharepoint Manager 201x Looks Dodgy
Doesn't it just! But it's from CodePlex, so it's probably okay. Probably. Be fair, your network is full of zombienets already, and you REALLY need to get rid of those libraries. There are four ditched documents in Education already. They keep e-mailing you. Fail.

Sharepoint Manager is findable in all three flavours, 2007, 2010 and 2013, at http://spm.codeplex.com/.

1. Download Sharepoint Manager.
2. Install it on the computer running the instance of Sharepoint you wish to Manage.
3. Profit! You can find the lists you're looking to edit in the folder browser, and their relevant properties in the right-hand window.
4. Navigate to the relevant site, with the relevant Drop Library.
5. Set the "AllowDeletion" to True
6. Save all changes
7. Return to your local computer from your remote browse window
8. Open your local instance of IE and delete the libraries as normal
9. Feel smug* about the world and knock off for lunch.

*Quietly, beautifully confident that you have just installed a back-end hack full of malware to a sensitive location due to your own incompetence at the field of Developing jack-squat, but even more confident that there are no drop libraries left. Decide this flavour of paranoia counts as a victory. Still knock off for lunch.

Smartphones and Museum Security

This is almost unrelated to Sharepoint, but directly related to management issues within software development. And museums.

I recently acquired a smartphone, one of them new-fangled pocketglass businesses. It is from Google because my friends are hackers and therefore when they hand down phones, they hand down the best phones, flat glass things with changeable batteries made in Korea like fashion will be for the next ten years, and the phones are generally scraped absolutely clean of nonsense. After receiving their phones, I place them in plastic boxes and use them until they are run over by cars.
Number Of Phones Lost To Being Run Over By Cars, Last Three Years: Six.
Suspicion of Value of Phones Generally: Very High.

As an outsider to how systems are supposed to work, this new pocketglass causes me deep-set suspicion.  Every major piece of software I have ever touched has seemed, once I got inside it, hideously broken. I am aware in my bones that things rot. For example, there is almost certainly a botnet in nearly every major museum, all over the world, because as museum staff we just don't have the money to prevent them; bureaucracy, of which proper software security is an evolved form, is hopelessly expensive. Having gone through the wringer of Microsoft's idea of the future, always a relay race of catch-up, I wonder how long it will be until these tiny perfect glasses begin to break. My hacker friends say not long.

There is an interesting problem here: banks tend not to store things that are actually irreplaceable, in the sense that more cannot be printed, but museums sure do. Whatever it is a given museum stores, it is almost certainly not multiple. We don't do multiples. There are no copies of this work. The work is the work and the whole of the work, and though there may be records, scans, and 3D prints of it, once it is gone, it is gone. And museums are almost always going broke, but lately, they are going broker, faster. The things we store are valuable because they are the sort of thing that is not taxed as income, and cannot be easily shared, except, of course, that it can. We hold the cargo cult in our bellies and our basements and our records-keeping. We are no longer truly funding or valuing our own research, but the things we were once researching still need to be preserved, at great cost.

A pocket glass radio that can control everything, including electronic locks, and that talks to other pocket radios by touch. I am wondering what their common cold is going to look like, and what doors it will pop open with its coughing.

The Quicklaunch

The Quicklaunch is the portion of sharepoint popularly known as the Left Nav menu. There is no way to mince words: the left nav is badly written to automate tasks, such that the net result is that said tasks become manual always. Here is a short list of its auto-generated things:

• Automatically generating suckerfish pop-out menus for new lists (everything is a list)
• Automatically changing various links to headings and headings to links
• Automatically nesting things (see above, cockroaches, mice, new pages)

The thing is, you can see the outlines of where this may have been helpful once. Similar to <span> tags all over everything (including this post), it's easy to see where coding has gotten in the way of ideology.*

This Is How The Left Nav Thinks

In Sharepoint 2007, as you flicked back and forth using the quicklaunch, the "level" of the quicklaunch would be set explicitly. This means that if you were on Page A, and a given link was Level 3, and you clicked that link, the link would likely become Level 1 or Level 2 on the inherited site. Depending on how competent the Information Architect was, that level might now display its siblings and parent... or not.

They have slightly sorted this out in Sharepoint 2010, except now, the support for your class inheritances is specified by name in the back end. This is then one o' them "lateral" changes where, like shoving your peas around your plate, something has changed without actually being corrected.

Explicit styling of the various inheritances, laid out in Core.css, will be to blame here - but so too are site definitions and weird automatic navigation and, of course, poorly-managed software development teams that appear to privately hate each other. This is a common problem at Microsoft, and will turn up later when we try to navigate workflows.

The Quicklaunch functions, displays, and generates differently in different Sharepoint site "definitions." Site Definitions** are code that sits on the server to tell sharepoint what to include when you try to generate a new site. At their root, Site Definitions are why you can't have nice things in Team Sites; the definition includes the features list, and someone in Redmond decided Team Sites don't want Group Lists by default. If you were better with C# and cared about this problem at all, you might fix it at root. You are bad at C# and are angry about having to fix it at root at all, so the actual problem here is how to design your information architecture and jQuery to repair the thing without having to touch Sharepoint proper at all.
**Ominous capitalization returns! Any time anyone ominously capitalizes anything, you are In For It. It, here, is A Sloth Of Bears.

So, first things first. Each Subsite is a new level of code. In previous versions of Sharepoint, it would then generate a little tag, like .level1, and you would style that. It worked okay most of the time, although around level 3, it started to get weird. Deprecated! Now things are inheritance-named in a mockery of Web Standards and you need to find out what their names are.

Sharepoint still only supports so many levels of subsite before it begins to get strange, and that level is 3. Level 1 is your home site, http://[YOUR STUPID SERVER:PORT]/. Level 2 is the first // address after that - so http://[YOUR STUPID SERVER:PORT]/Departments or /Office Documents.

That first // can be either a subsite, or a list, or a page. They will all style differently in your side navigation, and will all be the very thorny devil to reproduce elsewhere.

Level 3 is then the next // after level 2. Most of your inheritances, named explicitly, are probably working up to this point, and you are probably safe. The difficulty will come in at Level 4 and below, so... http://[YOUR STUPID SERVER:PORT]/Level2/Level3/Level4/Page.html.

Whenever you load http://[YOUR STUPID SERVER:PORT]/Level2/Level3/Level4/Page.html, your side navigation will completely lose its shit, even if you have done everything correctly. This is a long bug, caused, as mentioned, by two likely sources. The first is bad initial architecture. You noticed that the calendar bugs can sometimes be solved by naming them one thing, then undoing it, then naming them something else - this is like that. The preferences set when you launch the particular subsite matter.

The trick here is to set all of them, explicitly, to manual management when you create the site. Then you set up each link manually as you go, in Site Settings: Navigation. You can link those things and set them as headers. It is best to not set them as below one another, because then you will be faced with CSS-styling them to not Suckerfish all over the place, and from a pragmatic point of view, it does not matter whether or not they are nested - the headers and key levels will display differently no matter what.

Breaking Down The Quicklaunch CSS

.s4-ql UL.root > LI > .menu-item << this is typically what awaits you.

So. The Quicklaunch styles are nested in class .s4-ql. Inside of that is an unordered list, which is class-named "root." There is a chevron, which affects the nesting level of the LI in question, and which is the subject of much Sturm unt Drang upon the internet WRT correctness in published definitions versus legibility. Mostly, what this means is you can identify particular nests of tags by chevron abuse.

That this almost certainly means your menu is badly written is beside the point. Skip it. It wasn't made by Web People anyway, which, obvs.

Another chevron, and then .menu-item.

The naming structure here is pulled straight out of the existing Microstuff in Core.css. The trick is not writing any of this yourself, because it is to be assumed that you know what you are doing wrt Legible, Semantic Code and never nest tags such that chevrons are required for styling. So! The trick is FINDING these classes and then altering them to begin with. You will probably not have to build your own structures. Even using a standard reset for CSS styling is somewhat questionable before Sharepoint 2013.

Just find the thing marked .s4-(whatever) and style that.

*Do you know about web design ideology? No? Not at all? Pity. You have a long and adventurously boring amount of reading to do, mostly at Happy Cog's source code and A List Apart. Pro Tip: Their source code is almost certainly generated by Rails now.

Subsites Nest. Use As Few As Possible.

Subsites nest. They are like cockroaches or mice in that regard, because if you do not keep a tight eye on them, they can nest limitlessly.

This is handy, because they inherit their permissions from the main site. In theory, you need only permission the main site correctly and away you go; you can let the subsites inherit their permissions, and each one can be used to organize different material. Broadly correct use means you really can do this - finance can have a different sub-site than IT, and they can each be permissioned as separately as necessary. The trouble comes in later, when you meet your clients and become aware of their commitment wholly to bad permission structures. 

Anyone who works with Windows systems is already aware that MS sets permissions funny. Here is the speculation: because MS works with old, well-established teams, each team manages their permissions settings for their software a little differently, and they probably have no core permissioning squad with overreach for all things. So! MS stuff Sets Permissions Funny, and that seems normal until you begin working in a UNIX environment. Sharepoint subsites inherit this tendency, to break permissioning.

The other thing is that subsites under the main site inherit different permissions and different "levels" based on a variety of non-specified variables. The site itself will be fine, but the "level" it is at under the main site will affect how the subsite displays on the quick-launch. The Main site is generally counted as Level 1 (except when it is not, such as while you are in a subsite....) and the created sites are then Level 2+.

The trick here is that the quicklaunch automagically sets whether it is displaying sub-sites or pages or both, and then it gets confusing fast. Folders, in the URL, are sometimes at the same level as subsites, but they are not subsites, so they get tagged differently in front-end navigation. Or at least, they used to do; in Sharepoint 2010, the navigation is on generally shaky ground.

Because of the dodgy navigation issues, and how difficult it is to prevent Folder and Permission Nesting, it is for the best to limit the depth of subsites you support to one or two at most. At level 3, the quicklaunch becomes deeply strange, and at level 4 you basically have to rewrite everything because it ceases to inherit properly. 

Best Practices So Far:

1. No folders, ever, unless you REALLY need them for permissioning a document set with shared metadata.
2. Depth of no more than 3 subsites. Here is how your quicklaunch will come to look otherwise:
1. Main Site
1. Departments
1. Finance
2. IT
3. Collectables
1. This is all good
2. Hey no problem
3. Wait hang on something's dodgy here
4. Hey what's this door
5. AAUAUAUAGUGH GIVE ME BACK MY LEG
1. *smear of blood, something about minotaurs*
2. Projects
1. This needs collaboration
2. Everything is totally chill!
3. Man, this is such a convenient document sharing technology
4. I wonder where Rachel McPropellerGallery got to?
5. She was always so cool.

Why Is Sharepoint So Broken, Anyway? A History Lesson.

So why is it that nothing in Sharepoint quite works, even when you undo it later, or fix it, or it should be fixed but is not? Simple: there are handshakes missing all over the place. Parts of Sharepoint just do not talk to other parts. This is not part of the planned functionality of the thing, I mean, probably someone at MS really cares about the technology. It does work well in some very small, key ways.

The overall terribleness, though, is an extended part of what we call a Corporate Culture Problem. The problem is that, really, Microsoft is a risk-averse company with a risk-averse history working in an incredibly risk-forward industry, and it has not learned to hedge its bets in any sort of correct fashion. Microsoft has been late to the party while simultaneously refusing the party's best lessons for years now, then trying to make up its homework by copying the substantially better work of its peers.

The reason for this is simple: Microsoft lost all its corporate caché in the late 1990s, just as the first run of the webkids was leaving school. We'd land in the teeth of both the web crash and the recession, later, and in the meantime, although MS attracted Coupland - and therefore Gen X - it lost out on the much larger boom of the baby boomer's kids. It did this by developing a corporate strategy based entirely on disconnected systems and computer security, rather than openness, sharing, and peer review. The much larger generation of Web Kids learn by doing, mostly, because MS made its systems locked and university seemed expensive but the web itself has always been accessible. We are mostly self-taught - and likely to become moreso, as enrolment in CS programs drops.

They jumped too soon, and Sharepoint sucks because it is sharing software manufactured by a company that does not like to share at all, in any way, at any level. You can see this in the DNA of the software: there are errors, frequent ones, caused by what appears to be nothing more than bad team management. Everything is driven from the back end, in ways that once might have been good, but are no longer good, because they are not actually well-organized; organization is a function of sharing. They are dependent on assumptions and libraries that have to do with basic Windows architecture... which stops working the moment you recognize that the internet is an inherently unstable system.

But how can this BE, you ask, you who has paid good money for this system, and trusted the corporation selling it to you?

1. Sharepoint is built on seven separate base technologies, all of them huge, most of them legacy spare parts that have been dolled up like a late-run K-car and re-sold.
2. The dolling of these parts has not been well-managed, due to Sharepoint being, in large part, nothing but a weird profit centre for a long time. 
3. This has long historic roots. Microsoft fucked up at the internet way, way back - back when they were first getting into it - and have been engaged in playing catch-up as the fat kid ever since. 
4. They chased Dreamweaver with Frontpage, which became Sharepoint Designer after a rebranding.
5. Dreamweaver was terrible to begin with.
6. They missed Search and tried stealing Google's results for a while
7. Now they're stealing Apple's store design, and tablet design.
8. This is because Microsoft is a relatively old company, with a long legacy, working in an industry that is moving incredibly quickly. Their history is one of business software and risk-aversion, but they cannot make money without selling a new thing. 
9. Additionally, they are controlled by people who are uncomfortable with risk, presently unsure of  their core business, and worried about shareholder value rather than product quality.
1. This has to do with their age, which has to do with Nuclear War and The Boomers Have All The Money being a thing they were actually threatened with, where our age is still arriving, and is - see also Fiscal Cliff - likely to be more janitorial in its disasters. Cleanup in Aisle Twelve.
10. Their decisions are therefore being driven by marketing, rather than by actual use.
11. Because the company is not, even now, quite sure what the fuck the internet is for.
12. Which means that they are dedicated to selling their products to people who are afraid of the cloud
13. Want something shiny for their cash if they are going to hand it over
14. Who believe in Security
15. But are not able to grasp what in practice that means
16. And they are saddled with the buggiest, most hackable operating system and most difficult consumer-grade software because that used to be how you made money. 
17. No-one is sure how you make money now, but Brushed Aluminum and Shit Doing What It Says On The Packet is working out pretty well for most of them.
18. This scares Microsoft because, having missed out on the web, and utterly lacking any interesting technology except perhaps the xBox, where they continue to haul defeat from the jaws of victory, they are failing. Very, very slowly. You can fail for a long time before your company dies. You can make a lot of money failing, and take a lot of people with you.
19. Welcome to the life cycle of the American corporation, where, as we all know, money for shareholders is more important than people.

Unfortunately, unlike candy [Hershey's] , or beer [AB InBev], both of which are luxuries that can be put aside, the Microsoft problem has a direct consequence on the architecture of business operations in pretty well every English-speaking country. The maintenance of this software is boring, but necessary, as driven as it is by selling rather than making something worth using, and as important as it is to major corporations with a great deal of money running through them.

This is really pretty stupid, all of it, because it is like having two filing cabinet companies, and one of them simply has broken locks on everything. There is no end in sight, but the first filing cabinet company to do it better - thus far, Google - will have a mighty prize. It is already turning up in Android phones, alongside the new malware marketplace.

Unfortunately, twice, is that Google is now publicly traded, and is interested in documenting every last bleeding thing you do. It is very probably not long before this style of problem expands; how should a company be?