I was recently updating a view in a SharePoint List, the view was set up to use metadata fields to sort and group the content…lovely stuff. What I was required to do was to implement a choice field with a numerical order within it (i.e. 1. First step, 2. Second step, 3. Third step).
With sort order in List/Library views, it works with either alphabetical or numerical options ascending or descending. What I found was with choice fields operating as the number order, once you hit 10 the numbering system went out the window!
What you end up with is something like this:
1) First choice
11) Eleventh choice
12) Twelfth choice
2) Second choice
3) Third choice
and so on…
By default, SharePoint interperates the choice field as alphabetical so the way I got around this was to just use:
This gets around any issues with numerical values over 10 or having to create lookup lists or anything else 🙂
Explorer view in classic SharePoint sites has been a widely used bypass for users actually interacting with SharePoint libraries for a number of years.
Now in some cases that’s for good reason, from being able to upload multiple files easily in older versions of SharePoint to a familiar navigation of nested folder structure.
With modern SharePoint libraries, the old school ribbon has gone the way of the dodo…and so it seemed had open with explorer.
But fear not! If you still use IE you can still use the trusty open with explorer
How to open with explorer
Go to the library that you wish to open with explorer
On the right-hand side, press the drop-down icon next to all documents
Press View in File Explorer
Some weird stuff will then happen, where a classic 2013 version of your SharePoint site/library will open in a new tab and for me I got a message at the bottom of the browser window to allow popups from Microsoft then got another, more serious popup like this (multiple times):
I pressed allow to all of these then voila! we have file explorer!
File explorer only works for Internet Explorer, I tested in IE11 and it categorically doesn’t work in Firefox, Chrome, Edge or Edge Dev (beta).
I wanted to post this as I was banging my head against a brick wall for hours recently with this issue. Full credit goes to this stack overflow thread that described pretty much exactly what I was experiencing:
However, my situation was a little different so thought I would post this in case it helps someone else in future!
SharePoint 2010 environment using a standard SharePoint Designer workflow. Straight-forward workflow that runs once a list item is created, creates a document set in a separate library, then updates the list item with a link to the document set (plus some other item metadata). All this is wrapped up in an impersonation step that uses a site collection admin user account.
Why an impersonation step?
An impersonation step is being used because when you create a new list item using a workflow, that new item is created by the System Account. So on any new item created by a workflow, “Start workflow on create” will not work because system account is not allowed to start a workflow.
Intermittently the workflow would fail on creating the document set. The workflow status showed “The workflow could not create the list item. Make sure the list exists and the user has permissions to add items to the list.”. The outcome is “Unknown Error”.
After speaking with users this didn’t seem to affect everyone all of the time. It only affected some people occasionally but it was affecting one user way more than others.
This user was creating the list item in exactly the same way as others in the team. I overserved the user creating the list item and couldn’t see any problems with how it was being done. Yet each time we conducted a test copying field information from an existing item the workflow continued to error.
In my case, when I started to look at the list items where the workflow had failed, I noticed that the Name field for each list item contained a trailing space at the end of the text. I asked the user who this issue consistently affected to try creating new list items several times, copying the Name as normal but this time removing the trailing space and we no longer had issues!
Moral of the story…check for trailing spaces and beware!
Have you ever been asked to hide a list or library from a SharePoint site? If so, you go straight for selecting ‘no’ to displaying the list or library on the Quick Launch or removing it from the navigation. However, your eagle eyed users notice the handy view all site contents option and see that it is still listed there – they want it gone!
Luckily, all you need is SharePoint Designer and it is as simple as a click of a button…
(These steps were created using SharePoint Server 2010)
Open the site that where list or library resides in SharePoint Designer
Under Lists and Libraries – Select the list or library you wish to hide
On the main list settings page – find the Settings section
Check the Hide from browser option
Thats it! when you option the view all site content page now, that list or library will no longer be showing. Also, if you want to re-instate it at a later date, just un-check the box and it will re-appear.
This also works for SharePoint 2013, 2016 and SharePoint Online, under the site contents page.
Carrying on from my last post – creating a data connection, we are now good to go and begin to build our first PowerApp!
Just like setting up the data connection, creating a PowerApp can be a really simple thing to do.
However, I’ve found either creating a PowerApp from the SharePoint list or library is really quick and easy, but it doesn’t necessarily give you the most flexibility when it comes to wanting to do it your own way…
Creating a PowerApp
You can create a PowerApp from a list or library literally from the push of a button! Its as simple as:
Create your list or library, add all the associated columns and data you wish to be displayed in your PowerApp
Press the ‘PowerApps’ button on the list menu, then press ‘Create an app’
You’ll then be prompted to create your app, start by giving it a name and press ‘Create’
After a few moments your app will be created! It will open in the PowerApps web editor and you should see your list columns and data displaying in your shiny new PowerApp!
You can also take a look at the app in the preview to get a good look at how it operates and how the data is displayed…
That’s it! Your all set…but if you’re like me you’ll have some questions. Like, what if I want a desktop app and not a mobile one?
Well for that you’ll need to build an app from scratch, I’ll be going over creating a new PowerApp in the next part of this series so hold on as i’ll be posted the next part very soon!
If you’ve ever been in the situation where you try to edit a page in SharePoint and you see this seemingly unchangeable message appear at the top of the page stating:
“Page has been declared a record or placed on hold and is read-only”
Fear not! I’ve seen this message appear and it usually occurs when a user (or service account) is operating as a system account. This could have been set manually by said user if they have access to the web application via central admin:
If this is the case, you can overwrite the system account check in via SharePoint Designer. You’ll obviously need the correct permissions to access SPD beforehand! In the following example I’m using a SharePoint 2010 environment. To do this:
Connect to your web application in SharePoint Designer
Navigate to All Files – Pages
Right-click on the page that is currently locked
NOTE: You won’t be able to view the individual pages within each Page Library if you navigate through Lists and Libraries. This space is used to view and manage the settings for each list type you have. All Files takes you to the ‘root’ of your web application, where you can see everything that sits under the web application.
InfoPath, I really like InfoPath. I like the interface and how easy it makes editing custom list forms in SharePoint (especially if you want to make snazzy looking forms in SharePoint 2010). However, custom actions do not like InfoPath, not one bit.
Here’s the situation, we have a heavily customised custom SharePoint 2010 list which was leveraging InfoPath based forms. We were getting reports of latency when trying to open the InfoPath forms and the decision was made to revert back to the default ones.
Also, another requirement was to have a two edit forms for this list, one set as default with several fields omitted for end users – another one for administrators of the list. Once the edit forms were created I embarked on my journey of creating a custom action that would open the administrator’s edit form from the ribbon, utilising rights masks to make it only appear for those with adequate permissions.
I quickly found that this wasn’t going to work. I tried several times to create the custom action but it just wouldn’t appear. Even after reverting the list back to the default forms from InfoPath through list settings and deleting the InfoPath forms from server the custom action wouldn’t show. I found some useful conversations about this issue below:
After I realised the custom action approach wasn’t going to work, I made the decision to go down the route of having one custom edit form that would conditionally show or hide fields based on their permissions – the answer I found was within a XSLT conditional if test!
Here are the steps taken to hide a field based on a user’s permissions within a custom edit form:
Open the list you want to edit in SharePoint Designer
In the Forms section, open your custom edit form
Switch to Advanced Mode
Use the design view and select the field you wish to hide
In the code view, add the following code snippet above and below your field:
<xsl:if test="ddwrt:IfHasRights(2048)"> </xsl:if>
The end result should look something like this:
Save the changes
If this has worked, you should now be able to test the edit form as a user with the correct permissions and see the field, then verify that for a user without the relevant permissions it’s hidden.
Within the if test, the number corresponds to a permissions mask that assigns a particular value (i.e. 2048 = Manage Lists).
Here is a list of all the values and permissions masks:
I know what you’re thinking, what date format problem? Well this is something that’s cropped up for me time and time again so let me explain. Most requests I get for new SharePoint lists will usually contain a variety of custom date columns and said list will also require that the default display form shows a unique view of this data.
On the default display form, you will notice that the custom date columns will be showing data that looks like this:
Well this just won’t do, will it? The good news is we can fix it!
To be able to customise the display form, you will need to be able to connect to your SharePoint environment using SharePoint Designer, if you don’t have it you can download it from Microsoft here:
For this example, we are only focusing on one custom date column, at the end of the post I will summarise how to fix this issue for multiple custom date columns.
Open SharePoint Designer and connect to your environment
Navigate to the lists and libraries and open the list you want to change
Within the Forms section – New Form
(I’d recommend creating a new display form for no other reason than to avoid potentially breaking the active one).
Give the form a logical name so you can identify it at a glance as a display form (I usually go for DispForm2)
The code behind the display form will open, don’t worry too much about this we are only interested in a small portion of the code.
In the Ribbon – under the Home Tab – Press Advanced Mode
If it’s not already, at the bottom of the form – change the view to split view
Scroll through the design view of your form until you find the custom date field – select it
In the code view, make sure the following line is highlighted: <xsl:value-of select="@Start_x0020_Date"/> (NOTE: the bits after the @ will be the name of your date field)
If you amend this line of code to look like this: <xsl:value-of select="ddwrt:FormatDate(string(@Start_x0020_Date), 2057, 3)"/>
you should see something like this: 11 June 2014
Save the display form
Press Preview in browser to double check the format date function is working as expected
Close preview browser, close the display form
In the forms section of the list – select your form
In the Ribbon – Set as Default
That’s all there is too it! It might seem like quite a few steps but it isn’t too bad once you get comfortable with the forms code view.
If you have more than one custom date column that you need to format, just amend the code of each custom date column using the example above as a guide (just make sure if you copy/paste the code that each @ name is different.
FormatDate function and locales explained
What our updated code is doing is inserting a FormatDate function, which allows us to add the locale parameters to the end of our line code (the 2057, 3). The locale parameters control what the output of the FormatDate function will be, here are some examples of the outputs and locale parameters:
3/23/2009 12:00 AM
Monday, March 23 2009
Monday, March 23, 2009 12:00 AM
3/23/2009 12:00:00 AM
Monday, March 23, 2009 12:00:00 AM
3/23/2009 12:00 AM
23 March 2009
23 March 2009 00:00
23 March 2009 00:00:00
If you are looking for a list of all the available locales you can find them here:
This is my first ever blog post…scary! I’ll start with a really easy solution to a problem I was tasked with solving by one of our departments…
Ever wanted to completely remove any reference to the pesky NEW! icon from freshly uploaded documents or list items? Yeah me either…well if in case you ever felt so inclined to do so here are some very simple steps to remove the icons from any new documents or items on a page.
This example is a SharePoint 2010 web application with a standard publishing site collection active:
Navigate to the page you want to remove the NEW! icons from and begin editing
Add a content editor webpart to the page; I added it to the bottom of the page but you can add it whenever suites
Click on the down arrow to open the webpart menu – Select Edit Web Part
You’ll now notice the content editor webpart has changed, it will now say ‘Click here to add new content’, click here!
In the ribbon – Editing Tools menu – Format Text tab – Press HTML – Edit HTML Source
In the HTML editor, copy and paste this little bit of CSS:
Press OK on the HTML editor
Voila! The NEW! icons have vanished and we can move on with our lives…the next little bit is totally optional, but I think for completeness it makes sense to do. We’re just going to rename and hide the content editor webpart so that it’s not visible and any editors know not to touch it:
Click on the down arrow to open the webpart menu – Select Edit Web Part
In the content editor webpart menu – expand Appearance
Change the Title to ‘Do not delete’
Change the Chrome Type to None
Press Apply and OK
That is all there is to it, we have successfully removed the NEW! icons so they are no longer visible and also hidden the webpart which contains the tiny snippet of CSS that makes the change.