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.

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.

Special thanks to https://eointherealworld.wordpress.com/2010/12/29/sharepoint-2010-approval-workflow-with-content-approval/ for the kicker in this. 

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.

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!