In this post we look at a behaviour of document libraries in SharePoint that shows items as loading, and how to fix it.
I recently came across something I hadn’t seen before in SharePoint Online when working with document libraries. I was in a library that had more than 30 folders within it, and after the 30th folder the library just displays a sort of pulsing, loading screen similar to the below:
The thing is that nothing actually loads, there is no pagination or way to move to to see any more results, any additional files/ folders or basically any way to navigate further. I decided to dig into this to understand what was causing it and what can be done to resolve.
I found that the issue related to a view setting within the document library. The default view had an item limit set to “limit the total number of items returned to the specified amount”. Changing this effectively solved the problem, as once changed items are displayed in groups of 30, but a “show all” button will appear that allows you to see all the files/ folders. Here’s how to get to the item limit setting and update it:
Open the affecting document library > press the cog > library settings > more library settings.
Scroll down to views > select the default view.
Scroll down and expand item limit.
Change the radio button setting to display items in batches of the specified size.
Things to note
The number of items to display doesn’t have any bearing on modern views. In the screenshot above I’d changed mine to 100 items to display, but after the first 30 files/ folders, the show all button appears.
The show all button is problematic as if you are grouping within your view, when pressed it will apply an empty filter automatically – showing no files and ultimately confusing people. I’ve wrote about this in detail here.
This is an oldie but a goodie in my opinion, this post will show you how to use library filters in SharePoint to only show items/ files created, or modified by the current user.
The steps below will guide you through the process of updating the view of a list or library to only show items created or modified by the current, logged in user.
Open the list or library you wish to update
From the library actions ribbon > select the current view (for example: all documents)
Press edit current view
Scroll down the edit view page until you get to the filter section
Create the following filter:
NOTE: this example will only show items that were created by OR modified by the current, logged in user. If you want your filter to only show items where both these values are true, change OR to AND.
Press OK to save your changes
Now your view should have updated to only show items created by, or modified by the current, logged in user.
This example is really simple and easy to implement and there isn’t any real impact on your users as nothing is technically being restricted, just filtered out of the default view.
The flip-side of this is that in of itself could be considered a limitation if there is information stored within the list/ library that requires limited permissions. I’ll go into the options available for this later in this post.
However with that said, depending on what permissions you have in place for your list/ library, you could use this approach to secure the contents too.
Consideration #1 – Views don’t change permissions
A “back door” to gaining access to all contents stored in the list/ library would be to use a different view than the set default view to access all items (for example: if you created a new view to follow the below method, but left the default view set to show everything).
The solution to this would be to apply this filter approach to the default view, make sure any other public views follow the same approach and make sure end users don’t have elevated permissions.
Consideration #2 – Ensure permissions are set correctly
The only way an end user could bypass this approach without any “all items” views available, would be if they had the permissions to do so. The permission that controls this is called the Manage Lists permission, which is only granted via the Edit, Design, Full Control, Manage Hierarchy permission levels by default.
If end users aren’t in these groups, your in luck!
Consideration #3 – list/ library contents is not searchable
If you are using views to filter who can see contents within your list/ library then you will need to ensure this setting is updated if the contents needs to be hidden (below example is a document library):
Press the cog button > library settings
Press advanced settings
Under Search > change allow items from this document library to appear in search resultsto No
Consideration #4 – If it’s a list, enable item level permissions
With lists, in advanced settings there is an additional configuration option – item level permissions which allows you to specify which items users can read and edit.
As the heading implies, this consideration only works for lists in SharePoint as the functionality isn’t available out the box for document libraries. SharePoint Maven have written up what the two different levels of item level permissions you can set mean, which you can find here.
Columns in Microsoft Lists/ SharePoint lists & libraries have two main names – their display name that you can see within the list or library and their internal name. Sometimes you may be required to use a column’s internal name (for example: when creating column/list view formatting). There are several ways to do this, depending on the column so take a look below for more:
NOTE: In the examples below I will be focusing on lists, but the same applies for document libraries.
Option 1: list/ library settings
This is by far the easiest way to get the internal name of a column. All internal custom columns, plus several of the out-the-box column names within lists or libraries can be found by heading to list settings and clicking on the column itself:
Press the cog >list/ library settings
Scroll down until you see columns > select the column
The Field= end part of the URL in the browser will show you the internal name of your column (Modified By in my example)
Option 2: sort or group by the column
Some out-the-box columns don’t appear within list settings, but you can still get their internal name by either grouping or sorting based on the particular column. For example, the file size column is an out-the-box column that isn’t you won’t find in list settings. If you add this column to your list/ library view and sort you can get access to the internal name:
Click on the drop-down and press show/ hide columns
Select the column you wish to add > tick it > press apply
Select the drop-down next to your newly added column > either sort by or group by depending on what is available
For sorted columns – look for the sortField part of the URL to get the internal name of your column
For grouped columns – look for the groupBy part of the URL to get the internal name of your column
Option 3: REST API requests
SharePoint has a REST API service that allows you to perform CRUD operations by using REST HTTP requests. There is much more information about the SharePoint REST service here, but you can use GET requests via the browser to return information as per your requirements.
In our example, we want to return all the internal column names from a given list. To do this we simply need to send a REST request to SharePoint as follows:
This will return a huge wall of text, but if you CTRL+F and search for the name of your column or use a code editor you will find the internal name and display name:
Option 4: Microsoft Graph
You can also use the MS Graph Explorer to do something similar to a REST API request. The graph explorer allows you to create a run requests via an easy to use interface that also shows you the results. In our example I ran the following GET request via graph explorer:
In this post we take a look at the description column that is available within SharePoint Online document libraries and how to make use of it.
There is a description column available in modern SharePoint document libraries. This description column comes out of the box when you create a new document library, or when you add/remove columns from the existing Shared Documents library that comes with every Team/ SharePoint site.
The description column exhibits some very strange behaviour. First of all, when you try add it to a library view it does not appear within the properties pane, nor is it a column you can add via edit “columns”.
If you add the column into a document library view and switch to edit in grid view mode, the column becomes read only meaning you can’t add anything into any of the cells within the library.
This is more of a workaround than a solution as this appears to be a bug rather than desired behaviour. If you make the column mandatory, then optional it seems to do the trick! To do this:
Left-click on the Description column heading > column settings > edit
Press more options > set require that this column contains information to yes
With this setting changed, when you edit your document library in grid view now you are able to enter data into the Description field
Go back to edit the Description column settings and switch off require that this column contains information to make it optional
Add Description column to properties pane
Although the above will allow you to add data to the Description column, it will not add the Description column into the properties pane. You can get the Description column to appear by adding it to the default content type in the document library. Here’s how you can do it:
Press the cog > library settings
Under general settings > advanced settings
Set allow management of content types to yes
Scroll down to content types>select the document content type
Press add from existing site or list columns
Ensure the Description column is selected > press add
Go back to your document library, select a document and open the properties pane. You will now see the Description column is displayed in the properties pane, as well as being an editable field when you press edit all.
Bonus! History lesson and give your feedback
This description column appears to be a rather recent addition to all tenants, making it’s appearance in summer 2021 with the advent of Microsoft Lists. I went back to SharePoint 2010 just to double-check and sure enough the Description column was not present!
In this post we take a look at the common causes for the edit in grid view button to not be visible in SharePoint Online & Microsoft Lists.
Edit in grid view was made generally available to all Microsoft customers in February 2021 and is available for lists and document libraries in SharePoint Online or Microsoft Lists. I recently had an issue reported to me that the edit in grid view button was missing from the ribbon in a SharePoint Online document library.
After taking a look myself, sure enough this was the case and the option wasn’t present. The first thing to note about this particular document library was that the default view had grouping enabled on a particular column. In trying to replicate the issue, at first when I created a new document library the edit in grid view button was present:
I noticed that when I applied the same grouping to the view the edit in grid view button disappeared!
The solution for this is more of a workaround as this appears to be a Microsoft bug. I decided the best way to get around this was to create a specific view that defaults into grid view mode when selected. To do this:
With your library open > press the cog > library settings
Scroll down to views > press create view
Select datasheet view
Give the view a name > select the columns you wish to display > press OK
Now you have a view that defaults to grid view without users having to select it!
Other ways around this issue would be to:
Remove the grouping for the view in question to allow edit in grid view
Create a new view with the grouping removed and show users how to find it to edit in grid view
Unfortunately this seems to be an bug that although it has been raised with Microsoft, the SharePoint UserVoice has since been shut down so it’s unclear if it is being worked on or not. You can raise feature requests through the Microsoft feedback portal.
Bonus – free history lesson!
Out of curiosity I wanted to see if this was an issue in SharePoint 2010 as I was sure I would have come across it by now. As expected, it wasn’t and datasheet view works fine when views have groupings within them.
ID numbers, reference numbers, ticket numbers…this is something that regularly gets asked to be a part of any SharePoint solution or request based system. My first thought when this is required is “easy, we can just use the SharePoint item ID column and use that”. However, creating a simple calculated column that leverages the in-built ID column is not as easy as it seems.
My first attempt at creating a custom ID column involved creating a new calculated column, and appending some text before the ID and then inserting the ID column into the formula, like this:
The problem with this approach is that when new items are added, the ID appears to “slip” resulting in the custom ID column having no ID number being pulled from the SharePoint ID.
Custom ID column – modern SharePoint
Before you begin you will naturally need to create either a list or library in SharePoint, and the relevant apps checked as part of your O365 license.
2. The setup
Create a new column, with the type Number – I called this ‘solIncrementNum‘
Create a new column, with the type Calculated – I called this ‘solReqNum‘, later renamed ‘Request Number’
In the formula field, add the following: ="SOL-00"&[SolIncrementNum]
For the Data Type, select Single line of text
NOTE: for the Request Number formula if you want to prefix your custom ID with something else just replace what’s between the ” “ in the formula field above.
3. Build the Flow
Flow action: when a new item is created
Create a new flow from the template “when a new item is created, complete a custom action”
Give your Flow a name, I called mine “Populate Solution Request Number”
In the “when a new item is added” step, make sure the site address and list name are the same as the list you built the custom ID column for earlier
Flow: update item
Press + New step, start typing “update item”, select the update item action from the selection
Select the site in question, then copy and paste the List Name from the previous action
Make sure this action has the following fields set:
NOTE: make sure that when you set these fields, that the values you use are coming from the “when a new item is created” action.
Now when new items are created within the list or library, the flow will fire and create a new request number.
(this post was written using a SharePoint 2010 environment)
If you are using lookup columns in your SharePoint environment, one thing you may want to do is set the column that appears first, or is the default value in the lookup list when a document is uploaded into a library.
Now this solution is not a no code solution, but it requires very little code and is really straight forward to read and understand…
Step one – prerequisites
My setup to achieve this contained the following:
A custom list with each lookup value as a seperate list item (name stored in Title column)
A document library with a lookup column looking at the title in the custom list
Step two – configure the edit form
Open the list which is using the lookup column, make a note of the display name of the column
NOTE This caught me out while configuring, I naturally took the field name of the column from the URL string as opposed to the column name displayed in the edit form, make sure you use the latter as the field name won’t work.
Navigate to the lookup list where the lookup column is pointed to
Open the item in this list that you wish to be the default value
Open an item in a new window, in the address bar look for ID= and make a note of the number value as this is used for later
Navigate to the libraries edit form (just add /Forms/EditForm.aspx after the name of your list or library)
Press Site Actions > Edit Page
Add a web part > add a content editor web part to the page
Click inside the content editor web part > Under Editing Tools > Format Text press the HTML, Edit HTML Source button
Step three – add the code
In the HTML Source window, paste in the following:
(this post was written using a SharePoint 2010 environment)
So here’s the scenario, we have a document library that contains agendas, minutes, reports and other files related to meetings. The document library has a custom column called ‘Meeting Date’, a date column that is mandatory for all files that are uploaded.
We are required to create a view that is grouped by meeting date, sorted chronologically. Let’s give it a go!
Step one – prerequisites
My setup to achieve this was as follows:
A document library
An additional date column ‘Meeting Date’
Step two – configure the library
Navigate to the document library
Create a new calculated column called ‘Month of Meeting’
Add the following field reference in between the opening <ViewFields> and closing </ViewFields>
Add the field reference in the display order you would like it to appear in the view
Press the Save icon to save your changes
Press the Preview button to see your view in action in the browser
Now you will notice there is a new column being displayed “Path”, that is showing us the full location of the file or folder in the libary. You’ll also notice that this path will display data when at the library root, or in any folders or sub-folders in the library.
Taking this one step further, what if we wanted to show files of a certain type, then create a view that groups these files by their folder location? Guess what, that’s exactly what I did!
Navigate to your library > create a new view as before, this time base your new view off the one you just created
If you wish to only show files of a particular type, use the filter by settings (for example below is filtered to only shows Word documents)
Make sure “show all items without folders” is selected
Back in SharePoint Designer > Open up the view you just created
Scroll down until you see the opening <Query> tag and add the following beneath it:
With Microsoft retiring SharePoint 2010 designer workflows, plus the movement away from SharePoint Designer in general, a few readers have asked for a solution that works with modern SharePoint.
When researching this I considered whether suggesting to use SharePoint Designer 2013, as the above solution would still work in SharePoint Online using SPD 2013. But, as Microsoft say themselves although SPD 2013 remains supported, it’s depreciated – so I decided to go in a different direction.
The below example walks you through how you can create a flow in Power Automate to update a file after it’s been created to have the folder path shown in the document library view:
For this solution you will need to have access to create Flows in Power Automate, as well as an existing Document Library created in SharePoint Online:
Navigate to the document library you wish to show the folder path for
Add a single line of text column to the document library > give it a name (I called mine FolderPath)
Under the ellipsis, press Automate > Power Automate > Create a flow
In Power Automate, either use an existing, relevant template or start from blank
The trigger action should be When a file is created (properties only)
Set the Site Address and Library Name where you want to add the folder path
Insert a new step > select Update file properties.
Set the following values for the update file properties step:
Site Address: same as previous step
Library Name: same as previous step
FolderPath: Folder path
NOTE: The FolderPath within the Update file properties step is the custom column we created earlier. The Folder path (highlighted in red) is dynamic content available within the step in the flow. The folder path dynamic content is the path to the folder the item is in, relative to the site address.
Here’s the flow in it’s entirety:
At this point test and save your flow to make sure it is working as expected 🙂
Bonus #1 – turn your folder path column into a hyperlink column
So if like me you want to take this one step further, wouldn’t it be good if we could easily make our newly showing folder paths, actual hyperlinks to the folders? Well the good news is you can!
Navigate back to your document library > click on the FolderPath column > Format this column
Under Apply formatting to make sure FolderPath is selected
Paste the following JSON into the custom formatting box:
NOTE: for more information on turning field values into hyperlinks, check out this awesome sample from sp-dev-list-formatting.
Your FolderPath column values should now be legitimate hyperlinks that click through to the relevant folders
Bonus #2 – update existing files in the document library
This was another suggestion from a reader with regards to how to update files that existed in the document library before the flow was created.
Running a flow manually for individual files
When I began to consider how to do this I started by looking at ways to manually start the flow.
It appears the only real way to do this is to create a new column that adds a button next to each file, that allows you to run the flow. I’m not really enamoured by this approach as it doesn’t seem ideal to have an extra column to run a flow showing on every file in your library. If this is something you would like to pursue then I would recommend this great article by WonderLaura who has the process of creating a button to trigger a flow covered!
Update our flow to update all files if folder path is empty
My solution to this problem was to update the flow we created earlier to get the properties for all files in the library, then add a condition that checks if the FolderPath column is empty, then if yes runs our flow as before.
First, I added a Get files (properties only) action which gets all the files from the source library
Then I added a new Condition action, which simply checks if the FolderPath column we created is equal to null. You will also notice a new Apply to each action will be created
I then moved the previous Apply to each action into the “If yes” condition