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.

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:
• https://gist.github.com/pretentiousgit/6003434#file-xsl-tablegenerator
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/

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!

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.

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.