Kategoriarkiv: sharepoint 2013

Showing Birthdays and Job Anniversaries in the Newsfeed

anniversary-001

In our project we have a requirement to show birthdays and job anniversaries in the Newsfeed. The solution is simple (when you know it) but there has not been any information about it online, until today. I want to share a few lines of PowerShell code to enable Anniversary notifications in the Newsfeed. This desired piece of code was written by my colleague Emma Degerman. Enjoy:

The code retrieves the Timer Job that changes User Profiles, sets “GenerateAnniversaries” to true, then it updates the schedule to run it before the Activity Feed Timer Job and updates it. By the way, it is only applicable for SharePoint On Premises.

This is it, a quick tip for a great Intranet.

Debugging “What’s happening” in Communities

Recently an issue was reported about count mismatches in SharePoint 2013 Communities. The number of replies in category tiles sometimes is different compared to the community stats in the web part called “What’s happening”. The actual number of replies is 1 in the figure below. The user who has reported has tried to add, update and delete discussions and replies.

 

category-replies-count.png   comm-002

I have invested some time debugging this issue. It would be pity to not share my findings. Well the first thing to do was to determine the type name for the “What’s happening” web part. To do so just edit the  page and export the web part. In the exported .webpart file I saw that the type was Microsoft.SharePoint.Portal.WebControls.DashboardWebPart.

With that knowledge it is time to open ILSpy, an awesome and free(!) assembly browser and decompiler. Load the “Microsoft.SharePoint.Portal” assembly from GAC into ILSpy. Then use F3 to search for DashboardWebPart:

comm-003

The number of replies is retrieved from SPWeb.AllProperties:

comm-004

If the Property Bag does not contain it, it gets the number of replies from the list. The formula is as follows:

It means that it gets the number of both discussions and replies: ItemCount of Discusssions List. The number of Discussions is determined by the ItemCount in the RootFolder of the Discussions List. Discussions are List Items in the RootFolder (num2 in the figure below). Replies are saved in the subfolders, every discussion gets an own folder. The number of all replies are num3 in the figure below.

comm-005

After checking the web properties I could see that the number of replies there were wrong: 2.

The next step was to determine where and when the Web Properties are updated. The first guess every SharePoint Developer has in such cases is an EventReceiver. Here are all EventReceivers connected to the Discussions List:

comm-006

Allright, CommunityEventReceiver then:

comm-007

Found where the actual update happens: CommunityUtils.UpdateWebIndexedPropertyBag

comm-008

The method is used in DiscussionListCommunityEventHandler.HandleEvent

comm-009

There is a flag, flag5 that is used to determine if the Web Properties should be updated:

comm-010

But the flag5 is not true on Delete operations in some code flows:

comm-011

 

That’s it. So deleting a reply will not have any effect on “What’s happening”. But adding a new discussion will also update the stats:

comm-012

To summarize the debug session, there is an issue in the OOB code that misses to update community stats when deleting a discussion or a reply. Adding a new discussion, or a reply will synchronize the stats.

Tip: Use the weakest CSS selectors

I am reading Mobile HTML5 written by Estelle Weyle. It is an awesome recap and new knowledge about html, css and javascript. I want to highlight one of tips I got: Use the weakest CSS selectors (can be found on page 204).

We all know, that inline CSS and !important are evil. They have a higher level of specifity and override the standard cascade of the CSS rules. If you use !important, then it will be hard to override CSS rules when you really need it. After these two classic “evils” the evil number three is overqualifying of CSS selectors. You should really never add more classes or ids or elements than needed. Consider this:

It is often enough, you don’t need those:

SharePoint

In SharePoint sometimes we want override some OOB CSS rules. We have our own “namespace” to do that really simple. We have added a class to the html tag: “contoso-html”. Then it was really easy to update any OOB CSS rules, just copy the selector and add .contoso-html:

We also use less preprocessor and nest our selectors which has resulted that almost all of our selectors contain .contoso-html. Now back to the tip of that blog. This “namespace” made it harder to adjust CSS rules for special cases, like left navigation in the Search Center, we were forced to add more specific selectors, and selectors became bigger and bigger.

What I would recommend today is to skip the .contoso-html namespace in the CSS but keep it in the masterpage markup, use it wisely, meaning only if the original rule doesn’t work. Don’t nest too much in less files. Try always to find the weakest CSS selector. It is especially important in the SharePoint “markup djungle”.

How to stop the ItemUpdated-event from refiring itself in an remote event receiver

tl;dr: If you have trouble with stopping the updated-event from firing, compare what you want to change in the beforeProperties and afterProperties. If they are different, you should go ahead with your update, otherwise not.

This was my scenario: I had created a remote event receiver that was attached to a document library and was supposed to act whenever an item in the list was updated. The initialization of the event receiver looks like this:

And all was fine in the world. The event receiver was nicely attached and got busy when I uploaded a document. But then it started acting out and making trouble. I was trying to change permissions on an item and this was the part of my code that was creating the problems:

Inside my SPRemoteEventType.ItemUpdated I did an Update and making it trigger itself. Recursive SharePoint with no end in site.. If you’re dealing with a event receiver with access to server side code, this is not a problem.

Writing that makes your world pink and sparkly again. But this is the barren end empty world of the remote event receiver and no such this is available.

How I solved it

Googleing this helped me not one bit and my first solution was something I would like to hide at the bottom of some server (I don’t want to talk about it, let’s just say it had something to do with counting the seconds since the last update).

At your disposal on SPRemoteEventProperties you have afterProperties and beforeProperties, found by doing this:

And those were the key to the problem: how to act on the firing only when the user changes something and not when it updates itself? By comparing the values in the beforeProperties with the afterProperties I could see if they contained a difference. If it doesn’t, the updating event should not happen again.

In my case I was changing the value of a custom property named CMIsSecret, so if that property was the same in beforeProperties as in afterProperties (the values before and after the save) I should go on with the update, otherwise not. This was the method I created:

It checks if the property exists at all (it doesn’t if it is an ItemAdded-event and the property is custom made) and if it differs. It returns true if the property should be updated and the final usage looked like this:

Where ”ChangePermissionSettings” changes and updates the item.

Hope it helps!