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.

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.

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.

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.

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.

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!