New Office 365 profile experience

This is pretty exciting news. Microsoft announced that they will be rolling out an extended profile card experience across Office 365 to enhance the way you collaborate with colleagues and external contacts. There are several big improvements on top of the current user profile experience that we get on O365.

Some of the key improvements are

1) Quickly look up documents that have been shared with you, independent of how they were sent.

2) The new Organization view shows a complete picture of the highlighted user’s position in the company, including their direct reports and co-workers.

3) New profile card is integrated everywhere you see a person’s name on Office 365 without interrupting your productivity.

You can read details about this new change in the following blog post.

https://blogs.office.com/2017/03/10/introducing-the-new-office-365-profile-experience/

 

Renaming folder using REST API and Nintex workflow – SharePoint 2013

When working with Nintex workflow Item Update activity you would realize that it has different properties for document library and lists. For example if you are updating an item in document library it will allow you to update both Name and Title vs in Custom list it will only give you title.

This works perfectly fine until someone decided to use the folders in custom list and then have a business process to rename the workflow. Then Item update activity would not work in this case. Since to rename workflow you would need to set the Name property and not the title property but since it’s a custom list Workflow only property that is available to you is Title.

Workflow would run just fine and update the title but when you click on the folder it will display the folder Name and not the title.

With this business problem I have decided to use the REST API to update the folder Name. I am not going to talk too much about how to use the REST API with Nintex workflow since there is a good article on that. You can read about it at the following URL.

https://community.nintex.com/community/build-your-own/blog/2015/04/24/how-to-execute-a-rest-api-request-with-nintex-workflow

 

Only change you would need to do to change the folder Name is in the last step. In the last step you would need to change the property that you would like to update. So in our case it will become,

{

     '__metadata' : { 'type' : '{WorkflowVariable:listItemEntityType}'},

     'Title' : 'Folder Title',

     'FileLeafRef' : 'Folder Name'

}

And that is all you would need to do to rename a folder. Knew it would be simple but since I had to plug that REST API using the Nintex workflow there is some plumbing that you would need to do. 🙂

Using Javascript Object Model (JSOM) with Nintex Forms

Recently working on a project I came across an interesting scenario where I had to use Nintex form. As a part of the process the form will be querying multiple lists and displaying data on the form.

You can achieve this using the Nintex Form out of the box controls but there were specific requirements which could be achieved using the out of the box controls.

I decided to use the JSOM to complete the task and plugged in my JSOM code into Form’s custom JavaScript section. To my surprise when I ran the Nintex form nothing happened.

Quickly I figured that my code was getting executed before SharePoint finish loading all the files and required SP.js file was missing at the time of code execution.

So I tried Script on Demand to make sure that my function only gets executed after the SP.js is available.

Here is the code I have added to my Nintex form.

NWF.FormFiller.Events.RegisterAfterReady(function () {

               SP.SOD.executeFunc('sp.js', 'SP.ClientContext', myFunction);

}




function myFunction() {

.

.

.

.

}

Once I added that one line my code worked like a charm. So if you are working with Nintex forms and would like to use JavaScript Object Model then you might run into the same issue and in that case just make sure to use Script On-Demand.

SharePoint Discussion Board Quick Edit is disabled

One of the thing that you will notice that working with SharePoint Discussion Board you do not have ability to edit items using the Quick Edit. Based on my research Quick Edit option is only available when you have Standard View on your list. Since Discussion Board does not have Standard View Quick Edit option is disabled.

Doing research on this I came across this MSDN forums where the workaround was mentioned as using a PowerShell to enable Quick Edit on your Discussion Board list.

https://social.technet.microsoft.com/Forums/sharepoint/en-US/b5a74681-ba88-43e2-b406-82d25fa38b25/quick-edit-greyed-out-in-custom-list

$web = Get-SPWeb “YOUR WEB URL”
$list = $web.Lists.TryGetList(“YOUR DISCUSSION LIST”)
$list.DisableGridEditing = $false
$list.Update()

I have tried this on my development environment and it seems to be working but just word of caution, I am not sure if this method of enabling Quick Edit is supported.

So if you are using this approach I would advise you to validate if this is supported by Microsoft.

Get Site Collection properties using PowerShell – SharePoint 2013

Today I am just going to blog about how to get certain information about site collections to which SharePoint Administrators might not have access to. This question comes up quite often on SharePoint forums.

If you are looking to get information for the site collection or want to generate report on site collection properties then your best friend is Get-SPSiteAdministration cmdlet. This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets.

If you want to learn how to use parameters sets then follow the link below.

https://msdn.microsoft.com/library/dd878348(VS.85).aspx

For example if you would like to list primary site collection administrator and secondary site collection administrator then you would use something like,

Get-SPSiteAdministration -identity SITECOLLECTIONURL -Limit ALL | Select -Property OwnerDisplayName, SecondaryContactDisplayName

Here is the list of all the properties that you can get using this cmdlet.

https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spsiteadministration_properties.aspx

Similar to this there is Set-SPSiteAdministration cmdlet which can be used to set different properties for the site collections.

Cannot find s4-ribbonrow in oslo master page

Today’s post is quick how to when working with SharePoint Online Master page.

When working with SharePoint Online oslo master page, you will find that usual way of hiding gear icon would not work i.e. you will not find the div for s4-ribbonrow. Seattle.master still has that.

Reason for that is because Oslo and Seattle are different master page. You can read about the difference in the following blog post.

Coming back to hiding the gear icon you can target the button ID to hide it.

Either in your CSS or Script Editor web part add the following Style.

<style>#O365_MainLink_Settings{ display:none;}</style>

Where O365_MainLink_Settings is the ID of Settings button.

I hope this helps someone.