Monday, October 30, 2017

Changing SharePoint list item attachment to allow multiple files

I just got this email from a colleague saying he wants to upload multiple files as attachments to an item, and having to click add and confirm each and every one separately is quite annoying and time consuming.

So I wrote a little script that changes this behavior of the OOB file upload to allow multiple files selection.

Suprisingly, it works well with multiple files. there was only one part I had to fix, which was the label it shows before you save the item. It still shows the first file name only.

Here is the JavaScript code you can use to enable it on your system today. Just add this script in your new/edit item forms and it should work:

ExecuteOrDelayUntilScriptLoaded && ExecuteOrDelayUntilScriptLoaded(function(){
var oldShowPartAttachment = window.ShowPartAttachment;
var oldOkAttach = window.OkAttach;
window.OkAttach = function(){
var index = String(FileUploadIndex);
var index2 = String(FileUploadIndex);
if(index2 === index)//it means OK fail.
var files = GetAttachElement(FileuploadString + index);
if(files && files.files.length > 1)//more than one file
var text = "";
for(var i=0;i<files.files.length; i++) text+=', '+ files.files[i].name;
text = text.slice(2);
document.getElementById("attachRow" + index).cells[0].innerHTML = text;
window.ShowPartAttachment = function(){
var index = String(FileUploadIndex);
var files = GetAttachElement(FileuploadString + index);
files.multiple = true;
}}, "form.js");

Also, we will be adding this little script to a future release of our forms solution, so stay tuned for the update.

Let me know if you like it!

Edit: correction in the script, the if statement was missing the {}

Monday, October 16, 2017

SharePoint Online Search not returning all results part 2

Continuing the investigation into SharePoint Online Search not returning all results

We found that SharePoint search API has the "remove duplicates" flag turned on by default.

At first we didn't pay much attention to it, since the results we were missing were not duplicates...

However, after digging some more into it, it seems SharePoint Search was not only removing identical duplicates (meaning, the same item returned twice) but also similar duplicates - meaning items it deems are too similar to one another.

It is on by default, so you should turn it off on every request. It seems to have helped with our issues, we haven't been able to replicate this issue since we turned that off.

In query string, add:

In post, add:
{ '__metadata':{'type':'Microsoft.Office.Server.Search.REST.SearchRequest'}, 'Querytext':'sharepoint', 'TrimDuplicates'='False' }

Read more

The strange thing about it was - why did "Reindex List" button help in some cases? Perhaps there were two issues, we can not be sure.

Hope this helps!

Removing the hash from the SPFx bundle file name

Just a quick follow up on this topic Controlling SPFx bundle file name in production builds

It seems the latest drop of SPFx added a new setting that allows you to bypass the hash mechanism and prevent it from being added to your bundle file names.

I have yet to confirm this, but it seems you can add this code to you gulpfile.js:
build.copyAssets.taskConfig = { excludeHashFromFileNames: true, }

And this will stop adding the hash to the file names.

By: Franck Cornu

I will give it a try and update here if it works. See my other blog post on how to edit the file name and add the version number automatically as well.

Edit: I just verified this is working as of 1.4.0

Tuesday, October 10, 2017

My Interview with Collab365

Just in case you are interested, here is my interview with Collab365.

The event will go live in 21 days, join my session on SPFx development or check out the recording after (link to be posted after the event so stay tuned)

SharePoint Online Search not returning all results

When building the data source for our SPFx list aggregator web part, we noticed that in some cases when we make a request to the SharePoint Online Rest Search API, some lists or content were not returned by the search.

I cannot confirm exactly what happens or why, but in some cases lists that had their title changed were not picked up by the search service days and weeks after the change.
In other cases, lists that were created a few months ago were not returned at all unless specifically mentioning their list name in the query.

After investigating this for a long time, we could not identify a specific common cause for all these lists that would cause this to happen. We did however find many people experiencing the same issue with the SharePoint Online search.

One workaround we found that would fix the issue within reasonable time (usually within a few minutes up to a couple of hours) was simply to visit those lists, go to the list settings and under advanced settings to click the "Reindex List" button.

This seem to fix the issue, which makes me thing that the problem is with the incremental search crawl logic not picking up all changes properly.

Hope that helps you guys.