Tuesday, December 17, 2013

Sharepoint 2013 and Responsive Web Development

"Depending on what channels you define, you may want several designs, and so several HTML files, where each file gets converted into a separate master page. Also, each HTML file (and so each master page) can reference its own CSS file. Before you design your site, device channels are one of the first things to consider." Sharepoint 2013 Design Guide

Never let it be said that there was ever any party, anywhere, to which Microsoft could not be late. It could be at eight PM on a Thursday next to a transit stop, and they would take the streetcar in snow. Invited to an auto show, they would purchase a BMW, cheering as they did so BMW's long association with not only jerks, but jerks lacking the confidence and funding for an Audi.

Microsoft has missed the invitation once more, and this time, with responsive web programming.

via @Stammy
This is what the web looks like. Planning a resolution to display at and then laying out careful HTML for each view is unfettered nonsense, like trying to make Windows Forms work on the internet, or relying on the Table Ta-
I'm just going to pour some rum in this nog before we continue because of course they did this on purpose. The M in Microsoft stands for Malice Aforethought.

People, the internet is not static. It's controllable, but the control isn't yours and never will be. The control belongs to the people with money, which, even if you are a market capitalized publicly-traded corporation, you still can't control the other companies with money, and they are going to make tiny glass panels in every size they think will make a dime. Planning for a specific device resolution is insane, because you have no idea what people are reading their e-mail on. You could plan for the models on the left, but your interns own the things on the right, and you have no budget to buy an intern a phone. This means there's no device resolution planning, unless your organization wishes to both sign an exclusive contract whereby Apple gets to spy in every one of your supposedly private company documents, and then pay for you - and your intern - to have an iPhone. Your organization has no money for that! They can't even get it together to buy printers.

Microsoft has the power to repair this type of boondoggle, because they have the money to churn out Sharepoint, and that means that if they had the willpower, they could almost certainly pre-populate Sharepoint with actually functional responsive web layouts. They simply don't want to do that, because it would mean admitting that they are no longer the most important or most relevant company on the block.
You can tell they're trying to do better with usability, and also that they would rather chew off their own tits than cooperate with Apple and Google. Sometimes I find condescending phrases like "This shouldn't take long" with no process timer on a job that runs for an indeterminate length of time, so I know they mean well.

One layout, perfect mobile, served from inside the house. They could almost certainly put the work in to crack "automatically responsive image down-sampling" or "web fonts" or "any actual web problem," and for the moment, this sort of nonsense is just embarrassing. It's straight admitting they think they have a hope in Hell to be cool or useful or the company they were when they had a visionary running them and Douglas Coupland writing positive books about their nightmarish corporate culture as though it were a good thing.

Of course, Sharepoint is popular with organizations such as the NSA, where Edward Snowden was a systems administrator. So let it never be said that good things cannot come from purposefully obfuscated and repulsive bureaucracy: if it weren't for Sharepoint, we may never have known that the NSA loves spying through MS products like Skype best of all.

Thursday, November 14, 2013

System Account Needs Permission to Everything.

When you first set up Sharepoint, you will notice that it has the threat detection model of a particularly twitchy cockatoo, or possibly the NSA. It simply doesn't handle threats appropriately. People are locked in or out, permissions and abilities are set up strangely, and you may need to grant people List Management instead of Contribute to make sure that you can use lists to track data at all.

Sharepoint! It is working on it, okay, it is not its fault.

So! You have set up a list and some automagical workflows, and those workflows do automagical document approval, or possibly pass information to people's cellphones. But you are personally not logged in! Even though sometimes you just do it all yourself because it's simpler than trying to create an adequate permission system within the system.

You could maybe foist that one off on whomever manages your Active Directory, but knowing your "organization," a loosely-defined term if ever we've heard one, that's you.

The account that by default is assigned to permit and handle all automated flows within your organization is known as System Account, and it is absolutely essential that you don't kick it off your subsites or all of your automated approval workflows will break, because they do not inherit the AD permissions of the person to whom the approval task was assigned.

I am certain this is for good reasons, well, reasonably sure, and therefore, don't remove System Account.

What's that, you say? This superuser account which is specifically named by default to every library, group, list and site in the build may be a security issue?

Excellent.

Take careful note of it, least you ever need sell insurance paperwork from the mid-2000s to the Russians, and leave it on your structures. Taking it out causes headpain.

Wednesday, July 17, 2013

Upload Tracking Without Analytics

Sharepoint does a lot of enterprise-level things well, assuming you have many enterprise trained technicians to operate it, and learn the hidden languages of Exchange Server. Or whatever they're using back there, I assume it's something related to SQL. But let's say you're cut off from your out of the box analytics and you still want to be able to see each and every document uploaded into the site. Then you want to copy and paste that information into an excel table, presumably for Metrics.

There is probably a better way to do this sort of Metrics, but the thing about a closed development environment like MS is that it is not so hot at the SEO, and that means I can't find anything of value by googling "Sharepoint 2010 track user uploads." I have to believe this is traced in the logs somewhere, but really: there's faster way.

Here is where we get into customising the CQWP, or the Content Query Webpart, also known as the webpart that lets you see what is going on in your installation. The CQWP is the backbone of Sharepoint list investigation, and can be transformed to do a vast number of data-display tasks, as Heather Solomon once recorded (gosh she's great).

So. Open up Sharepoint Designer. Be prepared to revert everything, an awful lot. I recommend doing this in, say, a totally separate Sharepoint from your main one, because borking this will bork the site.
  1. Go to your Style Library.
  2. Copy your XSL Style Sheets Library into a new sub-folder so you can edit the CQWP main styles without destroying all your pre-exisiting content rollups for your whole site.
    1. Failed at that? Revert everything to the site definition in Designer. You saved your code, it'll be fine.
  3. Create a content webpart wherever you want it to live, note dismally that you will be writing some new styles for this, and export it.
  4. Open that sucker in Designer (Notepad++) and find the <MainXSLLink> XML tag - it should be Line 69. Replace it with:
    • <property name="MainXslLink" type="string" >/Style Library/XSL Style Sheets/EditedStyles/ContentQueryMain.xsl</property>
    • If you want to be fancy, you can replace <ItemXSLLink> as well. It's not as important, because it simply provides a list of item styles for your site as a whole, where the MainXSL is a control document that dictates how all your CQWP display.
      • Don't fuck with that. Really.
    • <property name="CommonViewFields" type="string">Author, Text;</property>
  5. Save that webpart and put it into your development page. 
    • I like to set a new title, limit the items displayed to 5 for testing purposes.
  6. Open your new EditedStyles/ItemStyle.xsl in Designer/Notepad++
  7. Add the Debug style because you'll be wanting it.
  8. Check in everything and publish major versions of them, or else nothing will change and you will be mightily confused.
  9. Reopen  EditedStyles/ItemStyle.xsl and add this to it:
  10. Publish that.
  11. Go to your content editor webpart and edit its properties to be the table generator. It should be displaying your author, the date the thing happened, and a link to the file's title.

You have now stripped off the reporting privacy of anyone who ever uploaded a thing to their corporate intranet. The HR department can see _all_. So can you! Someone probably programmed this in C# once! But it wasn't you! And now you've reproduced their work except sort of slow and front-end style.

Congratulations! We're part of the problem.

Helpful Link:
http://sharepoint.stackexchange.com/questions/55128/remove-li-wrapper-from-content-query-web-part-contentquerymain-xsl

Helpful Link #2:
Here's some stuff from Heather Solomon:
New blog: http://blog.sharepointexperience.com/
Evidence of smarts: http://blog.sharepointexperience.com/2012/03/introducing-the-magic-data-view-builder/

Wednesday, July 3, 2013

Force Infopath Form to Open in Browser

Approval workflows are tricky and fragile and counterintuitive, and a lot of what I do on the daily is customize them to get around that issue. I repair issues like how they don't approve content but instead set an approval on a whole new unrelated field, or how when you set them up on Infopath forms, those forms show up inside whatever damn application they please regardless of even system-wide settings that are clearly tickyboxed to "Open In Browser, Not Everyone Has Or Uses Infopath."

Tricky.
  1. Open Sharepoint Designer.
  2. Open the offending workflow.
  3. Open the workflow within that workflow that contains the renamed out-of-the-box Approval workflow.
  4. Tricky.
  5. Click "Change the Behaviour of an Individual Task."
  6. Find the one that sends an e-mail to a Task Approver.
  7. In the first line of the utterly useless bullet points is something that, nominally, will allow people to open a form for review.
    • It is not a form for review, it is a portal to a severe system lockup.
  8. Change the link from whatever nonsense it is using to
    [%Current Item:Encoded Absolute URL%]?OpenIn=Browser
  9. Celebrate, as this actually works.
Now your infopath document-style XML form opens in the browser for all your users who have InfoPath installed but not the system resources to run it. Good day!

Wednesday, June 19, 2013

Content Approval Tasks Followup

Content Approval Workflows, or the automation of pushed paper, remain the full meat of my daily life. This is because everyone wants signatures on everything in a bureaucracy, and yet they drown in the wash of paper involved in telling their coworker that it is okay to leave the office. The jealousy involved in a coworker being permitted to leave the building may involve a grievance.

There are, no lie, people in bureaucracies who take their vacations in half-hour chunks on Friday afternoon, and we are here to make that process, of shredding edges off their lives through meaningless, grotesque task-management, we are here to make that process smooth like hot butter and twice as scalding.

The underlying theory here is pretty straightforward. The content approval task, as written, has two elements: Content approval and task approval. This is used to control Sharepoint's extensive performance management metrics systems, which can be shattered like glass with a breath of air.

It is barely possible that these might be reusable, however: this builds on the Content Approval post a ways back.

Here is what we're doing: normally, the content approval workflow is decoupled from the task assigned by the process. We are hooking the two together, so that when your manager Opens the Task in their e-mail and hits Approved, they're approving the actual vacation request they just reviewed.

This is necessary because Sharepoint, by default, hides its content approval buttons in the task ribbon amid a broad swath of other clutter. It also likes to hide the "Open Tasks" button, which: I don't even care any more, you know? I've been learning Ruby. And Node. And they're much more fun than this business, as well as being better paid and generally not having a lot to do with Sharepoint, which is a career glass ceiling for practically everyone. There are better things to care about, so here is the step-by-step.


  1. Sharepoint Designer
  2. List you want to add the workflow to
  3. Add new workflow, on creation or change of list item Start Approval Workflow
  4. Rename Approval(22) something useful.
  5. Open Approval(22). 
  6. Edit individual Task Behavior, because we're linking the Task to the Approval, as versus keeping the two separate.
  7. Under Task Completion If Approved, add an item, Set Content Approval Status... and then...
  8. Under Task Completion If Rejected, set _that_ status to Rejected.
Now, let's clean up that list.
  1. Second workflow, dead vacation clearing
  2. On item created or changed and manual start
  3. If this CURRENT ITEM APPROVAL STATUS 
    • Approval status is a uniform column unaffected by the addition of other workflows, and it is what controls whether things go live or not.
  4. CONTAINS Rejected
    • Contains is important here, as is the capitalisation, because all of these methods act on slightly dodgy returns, and you can't tell if the thing is reading the ;#0Rejected or the actual string Rejected.
  5. Delete list item CURRENT ITEM
    • I'm presently favouring this because it works nicely on individual items, but I have been known to use un-limited scripts that wipe all rejected requests on the arrival of any new request.
    • Tryin' a catch me ridin' dirty...
This is more or less how you automate vacation requests.

Now you can watch people ask for half an hour off to go pick up their kids, and privately decide that, douchey as San Francisco may seem, at least they're not measuring your pee breaks.

Wednesday, May 29, 2013

Remove Information from Search Results

Privacy is such an enormous deal, isn't it? I mean that in the conventional implication of the word "enormous," related to Enormity, which means, basically, Fabulously Wicked, or possessing of "the quality of passing all moral bounds; excessive wickedness or outrageousness" thank you DuckDuckGo/Wikipedia. All of those are slightly slippery words, too, as is the word "slippery" itself, conveying not particularly good nor bad but both all at once, or perhaps that's only to me.

Privacy concerns are pretty well paramount in any organization that has groups within it organized to share information via e-mail, because of course good naming conventions insist that such groups are clearly labelled, but to label them means - naturally! There can be discrimination, for or against, and this is especially important when money comes up. Money always comes up. Particularly in worlds where it's money versus prestige which may be termed "awesome" - although perhaps Awesome is a higher calling - well.

When pulling People Search results in Sharepoint, by default, it reveals your Active Directory Group Memberships. This is sometimes useful, as you can snarf who's actually doing things in your building as versus saying they're doing things out of their memberships; if they fail to possess access to all (x) departments, there's no formal way that a person could be commenting across an appropriately broad range of documents to be key to the organization.

As with all snarfing of information, however, there is a downside, and that downside is that your Active Directory can also reveal which of the labour organization groups any given member of a given team belongs to, and with that information comes an implied reveal of people's wages and or benefits package. As many managers are aware, a key source of employee discontent is unequal compensation, and that is bidness you can be sued over. Particularly in prestige jobs, and let us recall here that prestige is a lie, there is no truth in it but for the truth that can be converted to money and from there into a better life. No money, no better life, no matter how good the title.

So it is best, by and large, for your HR department to hide group memberships. It is the sort of information you need for communicating with groups, but revealing who is in or out of those groups is not the best idea. Similar to badly-labelled Twitter reading lists, it will eventually bite you right in your rear end.

Here is your technical fix for this pernicious and timely issue in the world of the minor capitalist.

  1. Open your People Search page.
  2. Site Actions - Edit This Page.
  3. Click "Edit this webpart" on your people search return.
  4. Under Display Properties, unticky Use Location Visualization.
  5. Copy the Fetched Properties to a new text file.
    1. Save this in your personal code folder as OriginalFetchedProperties.xml
  6. Find the column marked "<Column Name="Memberships" HitHighLight="true"/>"
  7. Set HitHighLight to False.
  8. Copy the data back in, save your changes.
  9. Publish your page.
Voila! Apparent equality and no visible membership to upsetting organization groups visible at all, ever. Now think about your upcoming contract negotiations, and whether, perhaps, living in Berlin might ever be viable.

Wednesday, May 22, 2013

Content Approval Workflow to Actually Approve Content.

Content approval workflows on lists, out of the box, do not approve content. In this withholding  they are not unlike your parents, who never approved of anything you did directly, offering instead only cautious, private approvals that were in no way publicly visible, much less unconditional.

Rather than offering your craved public visibility and faith, the Approval Workflow, set on any given list, adds a new approval column to that list item. It is a conditional approval, like unto your sister's return to the house after that one Thanksgiving fight. Conditional, becolumned approvals can be useful if you need to have the items approved, yet private: Sharepoint does not offer a basic library setting to keep approved documents invisible to the wider masses after each document has been approved, preferring once again to set intricate account-based permissions. Sadly, when you generally go forth to approve a thing, it can be understood that people should be able to see that thing, which: not actually how the Approval workflow works. For Reasons, which are good, mainly within the bizarre, vaguely abusive, yet internally-consistent hierarchy of MS Office.

So! Content Approval Workflows: A backwards patch to fix weird privacy issues. Here is how to set a content approval workflow to actually approve and make visible the content you thought you were approving.
  1. Open Sharepoint Designer
  2. Go to the Workflows for your site.
  3. Click "Create new list workflow."
  4. Name your workflow.
  5. Edit your workflow, adding "Start content approval process on..."
  6. Click your new, underlined Approval action.
  7. Click "Change the behaviour of a Single Task"
  8. Find the step "When A Task Completes."
  9. In the If statement for Current Task:Outcome equals Approved, add a step.
  10. Set content approval status to "Approved."
Fun Bonus Project:
You could, in theory, make a copy of the main out-of-the-box Approval workflow, rename it "Actually Approves Things For Public Use Workflow" and then add this line in, at which point this would become a reusable tip. The article below details the intricacies of that; I have not yet had a server able to copy my default Approval workflow for editing, and therefore enjoy the opportunity to hone my skills doing it by hand every time.

Wednesday, May 8, 2013

User Profile Picture Change

User profile photos at work: uniformly unflattering! When you work in a building crafted entirely of prestige, cobwebs, and rare gold boxes, this matters a great deal. You, however, do not want to have to change people's photos. Ever. It's not your bag. You purposefully let yourself get the flu before your photo was taken, and then selected the chilliest and most blandly sociopathic of images to represent yourself to your peers, because a nice flat affect prevents idle chatter about childrearing, a topic which, as a barren homosexual, you are not permitted much of an opinion.

Mind you, were your actual opinions to turn up, they would also be unwelcome, although par for the course and widely shared (it's being done wrong and I wish people would treat their children with more respect).

So! People want to control their profile photos, this will make them happy as attempting to rear their young never has. Let's help.

  1. Open up Central Administration.
  2. Click "Manage Service Applications."
  3. Click "User Profile" for whichever service you have.
  4. Under People, click "Manage User Properties"
    1. Wait for seven forevers. Reflect that the server doubtless needs more RAMs.
  5. Select "Picture" and "Edit"
  6. Uncheck "Replicable"
    1. Reflect that this will instantly cause tremendous, poorly-documented issues everywhere. But whatever, you really are tired of babies' parents' performance of decorating choices.
  7. Check "User Can Override."
  8. Tickbox "User Can Edit Values For This Property"
  9. Okay.
    1. Seven more forevers.
  10. Return to your MySite, where you can change your photo. 
    1. Finally, Goatse for all.


Wednesday, May 1, 2013

Hiding The Toolbar, part 2.

As you may recall from Hiding The Toolbar in Sharepoint 2010, squirrelling away your user's ability to dick with things is relatively easy. However, times have changed, and your intranet is no longer totally useless. You may need to use forms, which write to lists, which send workflows to people, which are not quite useful but almost.

Therefore, almost everyone who uses your site will need to have Edit Lists permissions, so you need to change this:
<Sharepoint:SPSecurityTrimmedControl ID="SPSecurityTrimmedControl2" runat="server" PermissionsString="EditListItems">

The PermissionsString can be anything, but it can especially be ManageLists. This is one step higher in the permissions, which means you can still hide the toolbar while now letting people submit content to the pseudodatabase. Fun!

Wednesday, April 24, 2013

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.

Monday, April 22, 2013

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.

Friday, April 19, 2013

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.

Wednesday, April 17, 2013

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.

Monday, April 15, 2013

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.

Friday, April 12, 2013

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.

Tuesday, March 12, 2013

Off-Topic: Immersive Experience.

At lunch yesterday, I ran into one of the few Visitor Experience designers the museum world has to offer. He's a rebel: believes in the data-driven reporting and the calling back and the finding out what people remember about various events, about museums and about how they make their lives up out of things they've done. He likes interactive things, and he says the data supports it. This is a good thing! This is who you want in charge of your Visitor Experience. Someone who has their eye on the prize of more attendance and more people talking about your museum. So, as this is an internet hate machine blog, why I am I mentioning it?

I'm mentioning it because Marvel Comics is now releasing their Comix for Free on a lot of platforms, in order to get more people into Marvel Comix. This is a wonderful thing also. I like comics! Comics are an excellent outlet for people, who are inclined to like pictures and reading and literacy. Here is what I did not particularly like about the announcement, at least on CBC:
 "The project is an attempt to make reading a more immersive experience, like being inside a video game, according to Marvel executives."
Now, that the CBC made that the final line of the announcement is telling: I suspect the Ceeb reporter involved did not much like that line, either. A lot of people won't. Reading is not like a video game, after all: Reading is substantially better than most video games, the best of which require a great deal of writing, which requires, in turn, a lot of reading. Reading likely done in private without a lot of noise. Perhaps some jazz. Maybe some heavy metal. Making things requires concentration, which requires privacy and space.

The part that both my coincidental meeting and the Marvel announcement have in common is that they are geared towards taking introverted pastimes and public spaces and turning them into places that extroverts feel more comfortable. This is something I had not previously identified as a trend I loathe, and yet here we are. Definitive statement coming up, this is a full-on Personal Preference in public.

I like libraries and art galleries and museums for themselves, and while I believe they are indeed in desperate need of more market share, their marketing is ass-backwards, because they keep fucking chasing Cool Millenial Money or maybe Boomer Money and in doing so are losing out on the things they offer that no-one else does.

Every time an art gallery or museum declares itself a night club and then sets about losing gobs of money on trying to be a nightclub, while not damaging their precious items, they are reducing themselves from the church-like buildings they are, and they are losing out on the only unique thing they offer, which is their collections and the experience of being in the building with those collections. The collections, their display, research, and availability for interaction and remix; this is the unique thing. This is the product. It is what they sell. They sell access to the unique. The reproductions are useful, to an extent, for real... but the unique is unique. Which is another column, with people like Walter Benjamin ducking in to talk about what boils to a weird fetishism for religious paint and also Art In the Age of Mechanical Reproduction, which is art that is about experience of art, duh, that's what you have there. Back to the main point.

Introverts need to have public space of their own to do things like go on a quiet date, or read a book, or be involved with people while seeming smart to their friends.

There are ways to make immersive experiences that are memorable for these places that do not involve huge quantities of noise and people, but fuck I am offended that all the marketing directed to my demographic assumes we love a noisy night out.

Note: I am not opposed to an Extrovert Night once a month or whatever, you do you, it could work, I am open to New Things. Should my photo be up on compromat.ru, it would reveal many things, including my love of raves in former churches. Sadly, it would also reveal that I love churches period.

Anecdote is not the plural of data
Smartness, the public appearance of smartness, is hugely important to most of the introverts I know. Showing off smartness and good taste to potential partners is what we get in place of understanding how to talk to girls at parties. Instead of outgoing people-give-us-energy comfort, we get facts. Museums are full of facts and artifacts, and they are social spaces for quiet people. That's what they do well, much like comic books do the movies well for people who hate movies (Personal preference general statement #2: I fucking hate movies. Expensive, too short, too long, can't watch them in chunks and be absorbed momentarily, too many people involved in creation, probably I hate one of the actors, almost certainly there aren't enough girls, the theatre smells and I can't sit still long enough, I also hate YouTube videos over 1min, TV is better but not by much because Too Expensive. I like theatre, though. More humane, you get to show off your good taste to people, if it's terrible it's still fun).

The trend that I see that I hate most in the new economy is that no-one has figured out that there's money to be made letting people have quiet time in public, because noisy time in public is easier to sell to the people who are outgoing. Let me tell you this. There are not as many actually outgoing people as you think there are. That's why the event sucks. There are only so many actual party people, and only so many actually quiet people, and both sets of people need things to do in an evening.

This is, incidentally, the entire point of the first season of Slings and Arrows. That it's okay to love a cultural thing for being what it actually is, with the public smartness and the quiet bits left in, also that it's okay to have fun because you spotted the in-joke. That you don't need to trick people to like things and to sell them, even though sometimes your success will not be huge. That sometimes small is okay. Yes, this is a hugely privileged, elite position. But you know what?

After the Revolution, the imperial theatres were not, initially, a priority for the Bolshevik leadership. “It is awkward to spend big money on such a luxurious theatre,” Lenin said of the Bolshoi, “when we lack simple schools in the villages.” In 1921, Lenin told Anatoly Lunacharsky, the cultural commissar, to “lay all the theatres in the grave”—to destroy them—and focus on the urgent needs of the workers and the peasants: literacy, food, medicine. But Lunacharsky noticed that, even with civil war consuming the entire country, peasants and workers were happy to fill the seats of the Bolshoi. And it wasn’t revolutionary theatre that captivated them. It was, in part, ballet. They lacked, at first, a certain connoisseurship. Some workers, Ezrahi writes, were so ignorant of the mute art of ballet that they asked one another when the performers would begin to sing. Nevertheless, Lunacharsky insisted that the workers “ceaselessly demand opera and ballet.” The Bolshoi, in the end, was not razed.
Read more: http://www.newyorker.com/reporting/2013/03/18/130318fa_fact_remnick#ixzz2NKyyFkFa
People need something to aspire to, as much as they need a signifier of their own class status. That is how you get the middle class in the doors. You compliment their tastes. You give them hope. You give people something they can feel good about. Make people feel like they are part of the scene, whatever it takes, and they will pay your bills, even if you are curiously repellent in person and have a mad gift for skeeving out the mainstream.

Now, which is more expensive? Hosting an enormous fucking party or paying some security guards to keep your building open to an hour when people who work 12 to 14-hour days can take their date there? Making your audience feel wanted, included, exclusively in possession of good taste?

Marvel doesn't have to make this choice. Their interactive comic books will twist in the wind of weird sales numbers and will make them enough money, give or take. No bet there, although the core will remain people who like reading things quietly a bit at a time. Unfortunately, museums - by and large not backed by Disney - are going to have to sort this out. Interactive experience is absolutely valuable to us in this regard, and there are ways to have those which are not, inherently, inimicable to the actual experience of being in a museum.

People need quiet places to go and be with other people without having their life sucked out. Particularly teenagers, particularly bookish teenagers, and broke twenty-somethings, or thirty-somethings, or sixty-somethings. They will pay for this. They will pay small amounts for this, for the ability to gently fall in love with someone in front of your incredibly boring religious paintings and very interesting but under-displayed Shari Boyle sculptures. They will not necessarily pay $20 for it to start with, but eventually, they will, because they will have fallen for you and you will still be there when almost nothing else remains. This is the value of massed capital. You can starve them out.

Doctor Who Season One New Series says "Banks prefer a long game." As banks of massive scarcity and astonishing cultural capital, museums need to grasp their own true value. We make you look good to your peers. That, in a world filled with screaming movie theatres, is worth something. Time to take advantage.

Wednesday, March 6, 2013

The Nine Circles of Sharepoint Hell

http://jkymarsh.com/theninecirclesofhell

This is an excellent and accurate text about setting yourself up for even more professional Sharepoint development than that which I have already presented you with. I gather that this gentleman even controls his own Virtual Machines! Thrilling stuff. More to the point, the existence of this document proves two things:

  1. I am not alone in thinking of Sharepoint code apologists as relentless neckbeard fanboy optimists.
  2. Referring to alcohol as a valid coding solution is, in fact, best practice.
Enjoy.

Monday, March 4, 2013

Web App Service Stuck at 'Starting'

First things first: this is apparently considered normal and usual, much as any descent into administrative madness should be considered as such. Web Applications are hyuuuuge. Of course they sometimes fail halfway through launch, without issuing any sort of explicit message as to why they've failed! Then some of your web application folders will naturally vanish from your super-powerful Administration backend.

Why wouldn't they. This is Sharepoint's way of making you feel loved and necessary to the life and work of the organization. Never forget! Microsoft, after all, managed to eff over their Cloud users last week by failing to renew a digital security certificate. This is who you work for, however indirectly. These standards, you can trip over them, etc. etc., rampage, gin, etc.

Anyway. There is nothing actually wrong, and Sharepoint has not deleted, say, your institution's Performance Management site. It's still there. You can't see it, not even in Super Amazing Power Tools, because it's not turned on. It is not ringing le bell, as it were. Out like a light. Since you would like it to wake up and stop the screaming already, you need to get it started.

Here is where I got the information to fix this:
http://sharepointreferences.wordpress.com/2012/09/12/sp-services-web-app-stuck-at-starting-status/

The answer is type this Magic Machine Language code into what was once misleadingly referred to as PowerShell but is now called Sharepoint 2010 Management Shell:

stsadm.exe –o provisionservice – action stop- servicetype spwebservice

Wait the heart-stopping five minutes for it to work. Then:

iisreset /noforce

Again wait. Then:

stsadm.exe –o provisionservice – action start- servicetype spwebservice

This is what Sharepoint uses
instead of actual loading bars.
You will be seeing A Lot of it.
It will take seven forevers to load, during which time you will have not the foggiest idea whether or not it is working, because Command Line Terminals are old school and speak not of UX design, whereby the tiniest crumb of an animated gif of a loadbar is offered unto its users as a pacifier.

Your remote desktop will probably go dead during this time, giving you the impression that nothing is working, but it is a lie, everything is fine, secretly, though Sharepoint cares for your love and attention and is not telling you that it is actually okay under all that.

Wait five more minutes, click your remote desktop, watch everything load, and update your resume to "project management" with "strong soft skills" and "good at writing." Remember to leave off your strong tendency to ferret out the motives of everything around you, even things which apparently have no motive, such as software. Software is secretly full of motive. Things written by people, even people with autogeneration tools, tend to be.

Friday, March 1, 2013

PowerShell Is Probably Not Called PowerShell

"PowerShell" gets referred to eeeeerrywhar as "PowerShell," which is unfortunate for front-end web developers rapidly career transitioning into DevOps, because on the back end, where it is installed and you can access it, the application is referred to as Sharepoint 2010 Management Shell.

Now you know, which will be useful in repairing Monday's problem:
What to do when the web application service will only load halfway and will give you absolutely no answer as to why it is doing so, even though you changed the passwords everywhere you should have.

*ever-so-gentle glonking noise, the sweet noise of a bottle of comprehension uncorking in a fundamentally cruel universe*

Wednesday, February 27, 2013

Visual Webparts Can't Be Sandboxed

Visual Webparts Can't Be Sandboxed

Monday's grand snark-hunt yak-shavery was prompted by the Visual Webpart option in Visual Studio 2010 being disabled, as I imagined - incorrectly! - that the disabling was accidental or perhaps a curiosity relating to our terrible problems with account management.

Apparently, it is on purpose. You are not surprised either, please desist in your pearl-clutching, it is unbecoming.

Like most Sharepoint mishaps, there is a workaround, as discovered by Wictor Wlién, which involves skulduggery but does mean you can send the solution out to something as a nice parcel which can be disabled.

I hear Unix users take these things for granted, ungrateful sods.

Monday, February 25, 2013

Passwords Need Changing

Dear spiteful Jesus was this a long one to sort out.

There are basic accounts that are needed to run Sharepoint on the backend. Usually, they involve Farm Accounts and Content Accounts and it gets weird, there are passwords.

Here is a pro tip:

  • Active Directory does not, itself, force you to change passwords.
  • Microsoftware, however, does.
  • Therefore, it is very possible as a new, slightly terrible summer temp stand-in, to introduce a situation where a Content Retrieval Account's passwords are different on the front end from the back end...
  • .... and unchangeable. 
  • And untraceable. Why did I even have to mention this, of course they are.
To fix this, you need to go into your hive folder and do a search for every last thing called Web.Config.

Don't do this next bit if your site faces outwards, because you will get the h4xx0r3d

Add the following to each of the ... fifteen? Twenty-seven? I don't know. All the config files you find.
<configuration>
<system.web>
<customErrors mode="Off" />
</system.web>
</configuration>

Nest appropriately, of course. Save them. Back them up if you're feeling like you may die today.

Okay, now you can see some of your many mysterious errors. Having discovered the error - lo! The passwords do not match!

Go to the Central Admin page, go to the Security tab, find the offensive account, and change the password to something you can remember.

Send that password to your AD manager.

Never change anything ever again.

You deserve a whisky. Thank god you fixed this on Friday at 4:30, eh? SUCKER.

Edit: I see that Angry Me glossed over exactly what was going on up there! Well done, Angry Me, you are second in diplomacy only to Drunk Me.

The Web Config edits turn on explicit error messages from your server. Without them, you get a deeply broken screen with the "processing your request" GIF (the load screens in sharepoint are animated gifs of a load image, which does not relate in the slightest to the running job) and a thing which comments that there's been a runtime error, but even though your account has The Tallest admin permissions, you cannot see what that error might be.

There is no way to set error messages to turn up for some accounts but not for others, although you can turn on making error messages only show up for people in the building. (set customErrors to mode="RemoteOnly" then watch them break anyway).  The error messages themselves are charmingly explicit and will tell you more or less what's wrong: a password is broken somewhere. They will suggest you can fix the problem via PowerShell, which in my machine is apparently referred to as Sharepoint 2010 Management Shell, which is not the same name at all, thank you.

When you go to the management shell and enter the magic words they say will work, what will happen in this instance is that the shell will spit about ten lines of red text at you telling you the password you entered is wrong and cannot be changed that way.

The way it can be fixed is the above: Create a new password you can remember in Central Admin's security panel. Send it to the Active Directory admin. Carve a note about it into your cave wall in the hopes that the next island strandee will not have to do this again.

Friday, February 15, 2013

Fixing the Calendar with Javascript

This is about fixing Microsoft products with Javascript, the duct tape of the internet. What follows is a script written because someone needed to print a calendar, and Microsoft's custom Calendar Javascript generates a table, totally unrelated to any element of event handling, then sets inline values for each programatically-generated event item, which therefore cannot have their positioning overriden for print by any kind of @media command.

Needless to say, this causes the type of screaming that results in a new throat and an expense account at the state-run liquor outlet, as well as a strong interest in the opium trade, however! We must press on.

What follows is a script that will realign event cells in a more or less default calendar webpart so that they are well-spaced for printing after the fact. Possibly the difficulty of positioning these is related to having used a CSS Reset early in styling the site, possibly it is not, either way we're hand-writing margins in the backend now.

The function of this script is to align Sharepoint's calendar rows before printing to a landscaped piece of paper out of IE7 or IE8, so, ie, a hack job that in an ideal world, so different from our own, goes nicely with an @media -print CSS command. Only some of the @media -print stuff will work - table cell backgrounds, for example, will never show up or change colour, no matter how many !important tags you use.



This is that script. It makes things look ugly, but aligns them properly when you go to print something from IE7 or IE8.

function printCal(){
$('div[class|="ms-acal-item"]').each(function(index)
    {
       var styletag=$(this).attr('style');
       var stylestemp=styletag.split(';');
       var styles={};
       var c='';
       for (var x in stylestemp) {
         c=stylestemp[x].split(':');
         styles[$.trim(c[0])]=$.trim(c[1]);
       }

var boxTop = parseInt(styles.top.substring(0,styles.top.length-2));
var moduloTop = (boxTop%23)-10; // this groups things nicely in descending rows. Row 5 is at the top.
var interval = ((boxTop-(moduloTop+10))/23)-3;
var newTop = boxTop + (interval *6) ;
if (moduloTop == 5) {
var newTop = newTop + 18; // this part is where I lost patience with doing even lightweight math.
}
else if (moduloTop == 4) {
var newTop = newTop -15;
}
else if (moduloTop == 3) {
var newTop = newTop - 30
}
else if (moduloTop == 2) {
var newTop = newTop - 50
}
else if (moduloTop == 1) {
var newTop = newTop - 70
};
$(this).css('top',newTop);
    });
}

Notes:
- The default row height is 23.
- The default interval between grouped events in rows is 68, IE: Row 1 will be 23n +68px high to begin with.

This script does, in fact, work. Problematically, it does not seem to run on the various event handlers I have been attempting to call, because it seems that IE handles javascript much more poorly than Chrome. Triggering .click(); events in Sharepoint has proven to be a challenge. A hard challenge. Full of loathing.
IE runs Calendar.js after everything, and it is insidiously difficult to get your own scripts to run last, even if you do make use of our dear companion (Dear Leader) SP.UI.ApplicationPages.CalendarNotify.$4b; .

Having taken a copy of calendar.js off the Sharepoint hive and read through it to see if there is a more appropriate event kicker around, I now speak the seven languages of the damned which will summon forth the Great Old Ones from beyond the sky. No no, I lie, it was too much to parse and I closed it. Event handlers, buttons for incorporating this and launching window.print(); after it runs, all that is forthcoming.

Friday, February 8, 2013

Ugly But True: Printing Calendars.

Is there ever a time when a point about calendar functions is unwelcome? How about your Friday morning? I bet you want to feel better about your job. I have a fantastic way to accomplish this. Let's do it! Let's do it NOW. Let's make you feel better about your job, where you enter the code they say will work, and, by and large, it does just that.

This week, I am attempting to generate a clean, CSS driven @media -print variant of a sharepoint calendar, that people might be able to check their schedules online and have them in hand for meetings. This should be straightforward, until you realize that Sharepoint styles its calendar webpart via hard-coded tabular HTML, and styles its various events via programmatically-generated classes.

The classes are all named the same thing.

None of them are nested such that they float and clear.

Instead, they are positioned absolutely via whatever Hell-code summons them, and set to be 20px in height.

Should you change this, you will need to be changing the position of each and every event, as it is generated, even though it is not remotely telling you its complete title, even though nothing is visible, because paperless office, no-one prints things any more.

What appears to be their container table?

Not a container. That is merely a decorative suggestion, that Monday might perhaps arrive near the beginning of the week. It has nothing whatsoever to do with the actual items, except in that it may, somewhere within the bowels of the software, contribute to the initial value of the position:absolute; left:(WHY DID YOU DO THIS TO ME); tag.

Each .ms-acal-item is a block unto itself, and will need to be treated as such, for it will in no way respect the existence or positioning of any other .ms-acal-item object. Added to this is that somewhere within Sharepoint's default CSS tends to be a nasty inheritance habit, to whit: the pseudoclass, each one of which must be individually addressed in order to be repaired.

I have also spotted much use of the wily !important tag, which is a common threat upon this particular icy veldt.

This discovery has been brought to you by six hours of "this should be easy," two separate sets of developer tools, one in Chrome, one in IE, the print preview function, and the letter eff. None of this was a problem in Sharepoint 2007, whose ugly yet functional CSS mainly printed very well indeed.

Progress.

Incidentally, this utter, unfettered bullshit appears to be by design, via ASP.net development, and I gather is considered "normal" to "good" practice by some monkeys somewhere. They are not, however, the monkeys who read A List Apart and really believe in web standards.

Monday, February 4, 2013

Calendar Overlays

In case you're wondering where your sharepoint of the day is, this week is one of those weeks where the chiefest problem is Who Sets The Inheritance Policies Around Here.

Pro Tip: just say yes to everyone. They can all have their own subsite, and then when someone with a high enough pay scale asks you to migrate it, you can simply call various permissions across equivalently-levelled subsites. Behold the wizardry of programming!

Unfortunate Secondary Real World Observation:
Due to weird CSS inheritance things, and the way the levels are constructed, your largest piece of work here may be building a custom CSS mask to make everything look alike. They will notice that something is blue and in a slightly wrong place. They will notice! They will be angered, even if you have respected the corporate rules of inheritance and noted that individual administrators have control over their own sharing bailiwicks, which they may use how they like to share documents.

Webparts being in different parts of the page at the behest of different requesters will really mess people up when they visit subsites that are not their own. This is a UX concern, which normally would be enforced as an exacting, correct and identical policy, unless that gets you a load of pushback and you decide you'd really rather just let them have it their way, like Harvey's hamburgers.

Upon letting anyone have it their way, someone else will complain. If that person is not expected to work directly with that particular subsite, ignore them. If they continue to complain, use the Calendar Overlay feature to overlay whatever Calendar they were trying to look at onto their own Calendar. Permissions mean only people permitted to see both will be served both, your life will be easier, and the person in question will not be irritated by having to see the limits of their authority each day.

This is turn means you are less likely to be fired for being an unruly wizard.

Calendar Overlays
A calendar overlay is the name for a view of a calendar that is not within its own webpart. It is a view, therefore, of a list. To turn one on, make sure everyone who's supposed to be able to see that particular calendar has appropriate view access to it - IE: has been added to the (whatever subsite): MEMBERS group.


  1. Go to the main calendar, the one to which you wish to add A Thing.
  2. Click "Calendar"
  3. Click "Calendars Overlay"
  4. Click "New Calendar"
  5. In the Web URL box, find the calendar you wish to overlay. 
    • In this case, it's a sub-department with enough power to act independently from its nominal lead department.
    • Which is defying someone, I don't know, Dynasty has nothing on this place
  6. Click "Resolve"
  7. Select the appropriate calendar
  8. Select the colour you want
  9. Tell it to Always Show
  10. You can do this for a max of about ten calendars before Sharepoint starts to shake, rattle'n'roll
  11. Which is more than enough to establish the kingdom of Westphalia as fallen to the Visigoth.
Ta-dahh. No gin required. Miraculously. But if you wanted some anyway, I had some Dillon's this weekend and it was amazing. Try it with pear bitters.


Friday, February 1, 2013

Printing Your Calendars in Sharepoint


Calendar printouts can be useful when people are collaborating to install major pieces of equipment across multiple departments. Apart from anything else, having a large, visible calendar is valuable for ticking off the days until your health and safety violations are expected to spike. It has been said that people also like to use them to trace when department deadlines are coming up, or vacation days, and not just when Matt will come back from his dreadful skyjack injury. Large-format, public calendars! The trees are dying for something worthwhile, something really core to the life and work of the business. So, amid this excitement, let us address physical printouts of calendars in Sharepoint 2010.

How To Print A Calendar In Sharepoint 2010
  1. Receive complaint from department for whom you cannot remember activating calendar that calendars are printing funny.
  2. Reflect that you never activated any kind of printing functionality in Sharepoint.
  3. And that you have never heard of any way to print calendars, or anyone trying this before, because what is this, 1997, paperless office, mobile devices, dynamic updates.
  4. Get over yourself.
  5. Gnaw something.
  6. Wonder whether Sharepoint even supports printing functionality.
    • Optional: Sinking feeling.
  7. Do some research with Herr Google. 
    • Do not use Herr DuckDuckGo, that is a curiosity engine. You want answers, not ideology.
  8. Find out Sharepoint indeed does not support printing list views out of the box, hollow laugh, functionality costs extra.
  9. Google until you find a free version of a thing to let you print a calendar.
  10. Download the appropriate button from Codeplex.
  11. Deploy your sandboxed Codeplex solution, which does... a thing. Not the correct thing! Whatever.
  12. Decompile the thing in order to sort out why it isn't printing anything, even after the job spools.
    • This may legitimately be something weird to do with your printer.
      • It has always hated you and all people.
      • Printers are the reason why we don't want a singularity, actually.
      • Printers and AT&T.
        • Even in Canada.
  13. There really isn't any good reason. Perhaps there is a problem with the phase of the moon.
  14. Third party vendors. That's how we do.
Unrelated! Did you see that the Surface OS is 40Gb? It is.

Happy Friday!

Wednesday, January 30, 2013

Tag Prefixes Let You Do Server Things

Sharepoint is a weird agglomeration of technologies, built by a massive team of people, and it tends to need some handholding for the sake of its own security. Much like yourself, when you think about the hollowing of the middle class, wonder how you got here.

So, coming from a raw and rather old-fashioned web development background, where one might be accustomed to installing LAMP and going for it, what is a Tag Prefix?

As far as one can tell, a tag prefix tells your Sharepoint frontend page or layout to expect weird tags to turn up, which call specific underlying functions from a given document reference/the appropriate MS namespace. That's it, and that should be all, except they frequently have registration problems; "Unregistered Tag Prefix" as an error means that there is a tag somewhere in your page that is calling to a prefix that has not been properly entered up top.

Tag Prefix: a way of bringing access to various server controls into a front-end dev space.

The tag prefixes explicitly tell your page what things your page is allowed to call, presumably to protect your server and make sure everything is running the way it should. If you read the tag prefixes on your page, you can usually tell what functions are permitted within the page.

This means your page won't choke when it runs across <SharePoint:ListProperty /> somewhere within it, and, should you be genuinely writing your own libraries - which, should be stressed, you will probably not be doing if you're mostly helping people use the calendar function - you can make your own.


This is where a more professional blog, such as one that hearts the heck out of Visual Studio, would point out that you can develop in VS2010 and deploy things as Solutions to Server Farms and that Solutions come with a Manifest, but I do not drink kool-aid, I drink gin, so here, a very simple custom tag prefix use:

<% Register TagPrefix="booze" TagName="gin" Src="~/UserControls/TheBarCode.ascx"%>

This would allow you to call delicious <booze:gin Title="drink" runat="server"> and then you'd be fired forever because gin + servers = juniper-smelling magic smoke. The most exclusive only. It will take your whole budget to smell it even once.

Probably Visual Studio is coming into this soon. To the horror of all involved.

PS: I got Reddit'd. They said you shouldn't listen to me, because I am grossly inexperienced and deeply unprofessional, with many Wrong Answers, and that I should read more and blog less. Accurate!

Monday, January 28, 2013

Secret Words: Project Title for Your Page


By now you are aware that there are a million ways to do anything in Sharepoint, and that the published Best Practices have nothing to do with actual Practice. This is okay. Here are some Secret Words. You want them, because without them, you will hand-edit every page title.

These are the Secret Words to call up the property for your current subsite's real name, as in the Title for the  subsite, as versus for the page itself. 

 <SharePoint:ProjectProperty Property="Title" runat="server" />

This is distinct from what the edit panel lets you change:

<PublishingWebControls:EditModePanel runat="server" CssClass="edit-mode-panel"><SharePointWebControls:TextField runat="server" FieldName="Title" /></PublishingWebControls:EditModePanel>

The former just sticks the site's actual title on your page. The latter lets you edit the page title field. The more you know, the more you want to drink bleach. Happy Monday, here's a PJ Harvey video.

Friday, January 25, 2013

Reading Off The Web

By now you have worked out that pure Sharepoint content is not the point of this blog, no matter how I try to keep it on-topic. But then, it was named for one of those things that happen out in the real world, a cross-pollination, as it were. This is more to do with what happens when a straight arts and lit person discovers they are pretty good at puzzles, uses this ability to strip the skin off the systems running the world for money, and is, accordingly, horrified at what lies beneath.*
*Disorganization and people, mostly.

In order to escape the horror that is realizing the people who made these systems are, for real, people, and the biases are now hard-coded, I have become a reader. Readers have book lists. Other people know they're readers, and ask for book lists. Some of mine are long enough to reveal my profound disappointment with reality as it stands; this is not one of those. This is my short list.  Most of these are pop culture or pop science. All of them have roots in quite recent research or benefit strongly from broader background reading, but stand well on their own.

All of these are affiliate-linked, of course. But you can probably find them in the TPL, and I recommend you do so.
  1. vN, Madeline Ashby – Read this book! She’s local, it’s recent, it’s AMAZINGLY WELL DONE for a brutal story about all the weirdest bits of the internet. SO GOOD.
  2. Burning Your Boats, Angela Carter  – the collected short stories: I’d been recommending The Bloody Chamber to all and sundry, and, truly, it deserves it – but this has all that and more.
  3. Mauve, Simon Garfield – the history of organic chemistry through the development of artificial dye.
  4. Stiff, Mary Roach – What happens to people when they are no longer people, per se.
  5. Fun Home, Alison Bechdel – memoir is everywhere. This one is an excellent graphic novel.
  6. Stolen, Annette LaPoint – not for everyone, but for most people; a novel of the praries and contemporary geekdom and theft and murder.
  7. Gun Machine, Warren Ellis – Again, the violence may be too much, but I loved it.
  8. The Information, James Gleick – A survey of the history of information as quantifiable product. I’m reading it for class, but why shouldn’t others benefit?
  9. Zero History, William Gibson – the ending is a bit weak. I like his writing anyway. I want to live in that world.
  10. Ready Player One, Ernst Cline – I was ambivalent to this but in the end re-read it twice. So I suppose, if we’re going to Other Worlds…

Wednesday, January 23, 2013

Approval Workflows

Today we are customizing an approval workflow, which lets us peer into the bleak soul of the task assignment system. We are doing this through the lens of allowing people to request vacation time without filling out two copies of a form and asking for manual signatures on those forms.

Signatures: Good for cheques - someone should see where the money goes - bad for routine chores.

The first thing you will need to do is create a new subsite and set it up to handle calendars. Then add a calendar. Set up two groups of people in your permissions, one who can ask for things, a second that can approve things. Reflect that Sharepoint prefers groups, though you sure don't.

Got it? Good.

Calendar created, you need to get it to trigger a workflow programmatically to send things to the correct people. This will require a custom content type, so you can attach a name to a vacation request, and a workflow.

In Browser: Custom Content Types

  1. Site Settings >> Galleries >> Site content types
  2. Tiiiiny thing that says "Create" right there at the top
  3. Make your new content type, have it inherit from Event.
  4. Set it up as part of your custom content types group
    1. If you don't have one, make a new group and put it there.
  5. Head to your calendar.
  6. List Settings.
  7. Content Types
    1. Add From Existing Site Content Types
    2. Add your custom content type. I called mine Vacation Request.
      1. Why-eeee?
      2. This means that when you click "create new," something called "Vacation Request" will be available in your list of New Things Available, and this will make everyone in your office think you are a genius.
  8. Your Custom Content Types will only be available to your subsite unless you create them on the main site level.

They spend whole marketing presentations on this $h!t in the corporate world. Really. Thousands of dollars to rename an "event" a "vacation request." JOB. SECURITY.

Workflows
Workflows seem super-accessible and intuit- no. No they don't. Because graphic scripting engines are weird and because they can be added to any list item from about three places, workflows are heinously counterintuitive.

There are lots of "reusable" workflows in sharepoint, but they're not really reusable in any way that makes sense.

You can attach some to your calendar via the calendar page itself, edit "workflow settings" and good luck to you because these things are recursive and strange. Better: write your own via Sharepoint Designer.


  1. Open SP Designer.
  2. Navigate to your subsite.
  3. Open your specific list. 
  4. Look for the little window that says "workflows" and is empty.
  5. Create a New Workflow
  6. Add an "approval" by adding a step, and from the action menu, adding "start approval process."
  7. You can then customise the thing specifically to accept or reject whatever.
  8. But your rejected vacation requests will remain in play because rejected documents are thought to be good for editing. You need that cleaned.
  9. Add a second workflow*
    • *Sharepoint ain't give a fuck 'bout efficiency. You can, in theory, do this all with one. Do not bother.
  10. Add a step and load a condition: If Current Item:Approval Status equals 1;#Rejected
    1. Add the result: Delete item in Your Calendar Name
  11. It will pop a warning, because selecting that way will wipe any rejected item in that calendar, which is sometimes not preferred in larger document libraries but works fine for us.
So this is pretty straightforward, and it remains so as long as you do this kind of design, custom, every time. You can, in theory, build great reusable workflows. But as you can see, at least part of the clearing-out-ness requires a specific calendar name, and we have built this thing in a specific subsite. 

The other ways of doing this take three pages of writing and a quarter of gin. Just do it this way. It is the least painful.

Monday, January 21, 2013

Custom Layouts 101/LOL

Custom Layouts are one of those things you make once in Sharepoint and then never touch again. There are a lot of those things in corporate information design, which leads to much tut-tutting by consultants, but, for real: changing these things one they run well is made-up work. It is upsetting to your users when things change for no particular reason, although I suppose it might make them happy, briefly, to have a new logo, before they stop seeing the logo entirely because it relates not at all to their job of finding and editing the new loans agreement paperwork. Please be damn sure of your actual value addition before you start shoving things around from Tuesday boredom.

There are two basic views of a Sharepoint page, Edit and Read. You are the primary user of the Edit Page. Your user is the primary user of the Read Page. Your life goal is to be able to create a new splash page with all relevant bits and pieces in place in under ten minutes, that you can go back to writing your MFA on information theory and watching drones play catch on the internet.

Can I Create A Homepage That Automatically Pulls In, Say, A Calendar View And A Discussion Board?
No. You have to activate those as Site Features - templates that are available in your subsite - then create the relevant lists before you can call them. I expect you could program a custom Site Template that automagically turns on the appropriate Site Features then loads your desired List Types on the press of a button, but then you would have learned something and possibly have to admit to being Wrong About Sharepoint After All, and that cannot be.

Layouts are initially designed from the back end, in Sharepoint Designer, then pushed live, where you can include the most relevant webparts. There are some parts you can include back-end - anything that speaks to an extant list already loaded on your site, all content query webparts, that sort of thing - but you can't include views of document libraries or calendar lists, so you're pretty well just boned from the POV of backend development saving you front-end time.

Webpart You Can Have
File under Nice Things - you can have anything that rolls up data that's guaranteed to be there already. So things like the Content Query Webpart are fine. This is also where you'll be working with custom list-view webparts, may Satan have mercy on your soul. I like to force everyone in the company to see today's general announcements list, because secretly I am a reptile.

How To Backend Hurr Hurr Hurr
Do you have Visual Studio? Great, you're too competent for this blog, go away.
  1. Open Sharepoint Designer 2010.
    • 2007 had so many security holes many places refused to load it at all. 
  2. Under the Master Page templates will be Page Layouts
    1. Wait it's not there!
    2. You made your site using the wrong sort of Site Template. 
    3. Proceed directly to jail, no GO, no $200.
  3. Find a page layout you kind of like by clicking around and wondering about yourself.
    1. This will cause SPDesigner to lose its shit and try to crash.
  4. Copy it and rename it "ProjectLayout" or whatever you will remember.
  5. Edit This File, check it out, set your view to Split because this is like Dreamweaver, where you're going to learn to interpret their GUI gestures in both code and real time.
  6. The code section will be yellowed out to protect the worthy. Select "edit in advanced mode" and it will go normal. Some things will realign themselves.
  7. There are a lot of tags here that make no sense if you're used to semantic code.
Okay, so here we go: none of this makes sense or is documented in a really coherent way anywhere I have found it. There are certainly books you could buy, but you're at work already, so! Fun times are to be had. Know what you want, kind of? Great. You should create a subsite for yourself and begin applying random-ass page styles to it until the thing you want shows up. Yes, really. Then load the appropriate page layout into Sharepoint Designer and find the appropriate Secret Words, steal them, and paste them into your new layout.

Other Pointer: Do you remember when you loved semantic code and <DIV> tags and styling sites with CSS to float things around the page? Because I do not. Tables are your new friend, as whomever wrote this software was really big on tables. They are the simplest route to having web parts show up roughly where you want them, and as Sharepoint does not give a single fuck about bandwidth, usability, or mobile, you'll be just fine.

The below is a sample of a bog-simple page layout, but without any of the masses of tag prefixes you need to get the thing to run. As you can see, I do most of my customization in the browser itself, because my clients are not fond of shiny things and would much prefer to see, say, their calendar and their documents in the same page. Enjoy.

Friday, January 18, 2013

Web Parts, Why-eeee

Web Parts are things people have written that plug into the more front-end portions of the Sharepoint infrastructure. They are used to control and display your back-end information. Although there are a plethora of them, in practice you will be using only one or two. These are the Content Query Webpart, in Sharepoint 2007, and Are All Of These Actually The Same Thing? in Sharepoint 2010.

Sharepoint 2010: Drop A Block In the Page and Call It A Day
All lists (everything is a list in sharepoint) can be displayed as webparts, which are functionally tiny windows within windows with their own display settings. Each list you have on a subsite automatically generates its own page, with a webpart in it, which displays the content of the list according to settings you choose in the toolbar, hopefully while sober and lacking the flu.

Document libraries, calendars, everything - you set what to display on their page, and then all future views of the list will just load those settings, correct?

False.

Those settings are not centralized, they are page-specific. That means that every time you need to load a given view of a list into a page, you're gonna be setting how you see that list. Even if it is an extremely specific set of preferences about, say, group selection and display.
JOB SECURITY.

There are ways around this - for example, setting everything on the one calendar page and then exporting the webpart with all its settings, and loading it to whatever page you end up with - but in practice, this will lead to you storing hundreds of XML files with various almost indistinguishable webpart settings, which you use in two places on your site; the first where you made it, the second on the landing page for the subsite. Not particularly efficient in real terms.

So in practice,  you get to hand-edit every homepage, and prepare to answer a lot of questions about where the documents are actually living. This is marginally better than managing check-ins, and slightly worse than sorting out version control.

Performance Management Easy Achievement High Score
Do you need to game a performance management system in advance of Spring Review? Oh shit you might. Great. Customize twenty of the damn things and stuff 'em in a folder and then you suddenly have quantifiable job metrics for data-driven review. Well done you. Your horrific cynicism will carry the day yet.

Wednesday, January 16, 2013

Hiding The Toolbar in Sharepoint 2010

The Toolbar is one of those in-between metaphors in the Sharepoint 2010 environment. It is designed to make things more comfortable for people used to Office 2010, yet it makes using a web metaphor complex and somewhat needlessly difficult. Here is how you hide it.

Why You Want To Hide It But Not Pull It Entirely
Really, Sharepoint is constructed to rely on the damn thing. Unfortunately, if people don't have permission to do shit on your site - and most of your users are readers, not contributors - you don't really want them poking around the various grayed-out links.

  1. Pop open Sharepoint Designer and find the site you need to get into.
    • Side nav - Master Pages
    • Your custom master page from when you wiped the basic sharepoint page.
    • Edit file
    • Check out the file.
  2. Look for this tag: <SharePoint:SPRibbon runat="server" PlaceholderElementId="RibbonContainer" CssFile="">
  3. I like to label mine things like <!-- === THE RIBBON STARTS HERE == --> for future reference, but all that should be in your minimal master page.
  4. The next thing to do is decide what permissions people should have before they can see your ribbon. I like "edit list items." 
    1. <Sharepoint:SPSecurityTrimmedControl ID="SPSecurityTrimmedControl2" runat="server" PermissionsString="EditListItems">
    2. every other piece of ribbon content goes in here.
    3. </Sharepoint:SPSecurityTrimmedControl>
So how does this work?
Permissioning is still your only job. You now have two groups of users, Everyone, who have read permissions and can't touch anything on the site, and whatever group you assign to have other permissions. In theory, this will work to control the whole site - the ribbon will just not be there when they log in. 

Sometimes You Just Need To Trust People
However, this means that you need to grant pretty high permissions to anyone who wants to edit anything on the site, and that includes things like, say, a calendar. For some reason, presumably because the ribbon is set at the master page level, you can't just issue edit list permissions on a specific list (everything in sharepoint is a list) and have the ribbon load properly on that list alone.

In theory, there is a provision for this by "allowing" people to "hide" or "display" the ribbon.

In practice, for the group you want to be able to edit and access that calendar (or list generally), create a group, give that group Edit List permissions on your site, and trust in the panopticon to let you know who, exactly, fiddled with what. They probably won't, you can definitely see what they did if they do, and turn on version control for the site. Welcome to systems administration, which - much like the future generally - is slightly less than promised.